Open lukecc42 opened 2 years ago
Unfortunately i can't really help you with your problem; aside from suggesting you check every assembly/dependency your software is using -- including each dependency's dependencies -- whether some have dependencies on Newtonsoft.Json of a different version than your project is using.
But i want to point out that "Runtime version" in your secreenshot refers to the version of the CLR (the Common Language Runtime) required to execute the IL code in the assembly. Do NOT mistake it as Framework version.
All the .NET Framework 4.x versions (including .NET Framework 4.5) use the CLR v4.0. Thus, naturally the Newtonsoft.Json library version for .NET framework 4.5 would list runtime version 4.0.x (again, runtime version does not equate framework version).
(In comparison, the older .NET framework 3.5 uses CLR v2.0. And fortunately, starting with .NET 5, there is no separate runtime (CLR) version anymore that could differ from the .NET version, so such confusions will be a thing of the past...)
Hi elgonzo, i think you are right on below part, but the version above is the .NET Framework 4.0 version of Newtonsoft library, it shouldn't display targeting 4.5 (as displayed in the upper part of the screenshot). In my opinion this is leasing msbuild giving error on build. The strange thing is that if the assembly is directly referenced by a .net 4.0 library it would compile. Instead if you reference the secondary library by another application, msbuild is getting confused about the mixed targetting. Also you can note the same incoherence decompiling the dll with a .net decompiler (I used here dotPeek I attach another image below) I strongly suspect that in the last 13.0.1 release for .net 4.0 on nuget something has gone wrong and some 4.5 targetting has been left
I repeat you can also see yourself creating a blank .net 4.0 application, loading .net 4 library and looking in the reference with assemply explorer you can see as in first screenshot that the system shows a .net 4.5 targetting
On my side, on our company framework we have reverted all reference to 12.0.0 and now all build servers are ok
I don't have any experience with Assembly Explorer (it's a feature of jetbrain's Resharper, right?).
But note that both the error and what you see in Assembly Explorer are consistent. Both strongly indicate that there is actually no Newtonsoft.Json assembly for .NET Framework 4.0 present during your build process, but in actuality Newtonsoft.Json assembly for .NET Framework 4.5 is present. The error MSB3275 indicates that a dependency could not be resolved because the dependency was for a framework version higher than the depending library or the softare project build target allows. (English error message quoted from the MSB3275 documentation i linked to: "The primary reference 'reference' could not be resolved because it has an indirect dependency on the assembly 'assembly-name' which was built against the 'version' framework. This is a higher version than the currently targeted framework 'version'.")
I also took a look into the nuget package for Newtonsoft.Json 13.0.1 and the config/spec files and assemblies contained therein, and i did not find anything suspicious there.
Thus, based on the given information i tend to disagree with your statement that
[...] the version above is the .NET Framework 4.0 version of Newtonsoft library, it shouldn't display targeting 4.5 (as displayed in the upper part of the screenshot).
Given that both the error message and Assembly Explorer agree on the Framework version, i rather tend to believe the display of Assembly Explorer is truthful, and that the version above is indeed the .NET Framework 4.5 version of Newtonsoft library, not the .NET Framework 4.0 version as you seem to think.
I do not share your suspicion that the Newtonsoft.Json 13.0.1 assembly .NET Framework 4.0 or its manifest is somehow borked. Based on the (somewhat limited) information in your report, me looking into the nuget package, and a lack of other people reporting issues similar to what you seem to suspect, i don't think that this case is likely. I am not saying that this is impossible; but i am saying that all i know about your issue is implying a different probable cause.
Personally, my suspicion is strongly aimed at your project and/or build process somehow pulling in the actual Newtonsoft.Json 13.0.1 assembly for .NET Framework 4.5 instead of the intended/desired variant for .NET Framework 4.0.
Double check that your project files use the package reference for the official Newtonsoft.Json nuget package or a direct reference to the correct Newtonsoft.Json assembly DLL, and are not by chance referring to an unofficial Newtonsoft.Json package or assembly that has been modified by a 3rd party. Also make sure that the nuget.org feed is being used to fetch the Newtonsoft.Json nuget package.
Is the local nuget cache perhaps at fault? If the problem is not with your build configuration/process somehow referring directly or indirectly to the incorrect Newtonsoft.Json assembly variant (which i still do not rule out; i don't know enough of your project and build setup to discard this possibility outright), perhaps the local nuget cache got corrupted somehow? (This could possibly also explain why a simple switch to Newtonsoft.Json 12.0.0 allowed for a successful build.)
If you are willing and able to try, try removing Newtonsoft.Json version 13.0.1 from the nuget caches used by your build servers (so that the nuget package will have to be fetched again), then clean and rebuild your project/solution, and see whether it rectifies the situation. Alternatively, to verify that the local nuget cache is not corrupted, you could also manually download the nuget package (https://www.nuget.org/packages/Newtonsoft.Json/13.0.1), extract it (for example with 7zip; nuget package files are essentially ZIP archives) and do a binary comparison of the files in the local nuget cache and the respective files from the manually downloaded nuget package.
Hi elgonzo, thanks for your assistance, actually I am going to think the problem as you say is not on dll itself but in our build servers configuration. I managed to get the same informations above on same servers by jetbrains tools reporting 4.0 on same dll and I checked the dll version also by binary decompiling (ILDasm) and it is reporting correctly 4.0. The odd thing is that I have this problem only on latest version of dll and not on previous one (12) that works smoothly. It seems that in some condition the .net framework build compiler got confused on dll default targeting behaviour I must take some time to make a standalone clean virtual environment to make isolated tests to reproduce it and understanding what's happening
Hi I made some tests, and we can definitely archive this. The behaviour is specific for the machines where I had the problem and I can't reproduce on other clean machines. I think the msbuild error is misleading perhaps for a bug of the specific toolset used on these machines. What I think is that the compiler get confused on how to retrieve the correct dll referenced by the current project and somehow it finds a wrong version on some machine path. The error goes away simply changing dll version, toolset or also putting the correct newtonsoft linked dll in first library reference directory.
Thank you anyway for the help
It seems that some issue is inside the manifest of latest version for .net framework 4.0 Getting the dll by NuGet at first level of reference it seems working (viusal studio seems to view it as .net 4.0 runtime assembly), but when you reference the assembly at second level something is happening on some machine having also .net 4.5 We got multiple error of this type: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3275: impossibile risolvere il riferimento primario "XXXLib" perché ha una dipendenza indiretta dall'assembly "Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" che è stato compilato con il framework ".NETFramework,Version=v4.5". (message is in italian, I hope it is clear)
In effect viewing the reference in "Assembly Explorer" reports that something is targeting 4.5 Instead with version 12 all works fine