Develop Reference

How to trace resolving process of nuget package references

I have a solution with multiple projects in it (~400). A lot of them are using newtonsoft.json library. Some of them are using different version of the library. In a host project for web app, there is no direct reference to newtonsoft.json. Also, I believe, there are dependencies to packages that depend on newtonsoft.json. However, in bin folder of that project I began getting newtonsoft.json 9.0 instead of newtonsoft.json 11.0 as it used to be. And it causes load exception in runtime due to invalid version. If I include direct reference to newtonsoft.json 11.0, it still puts version 9.0 in the bin folder even if I clear all bin,obj folders. I use PackageReference for managing dependencies, and everything is in .net 4.6.1; I use binding redirects to resolve issues with different versions of the same library.
My question is if there is a way to diagnose how particular dll of package ref appears in bin folder? I would like to see some sort of comprehensive trace of dependency resolution so that I can fix it without using "trial and error" approach.
Upd.
Actually, thanks guys for pointing to structured logging. You are the best! So the issue was that one of the project had <OutputPath> pointing to the bin folder of the host project. So when the project was built, it was overriding binaries in the host project. Apparently, build order has changed due to continuous reference shuffling and the project with wrong <OutputPath> started building last. To find this out 1) I Newtonsoft.Json was recorded in DoubleWrites section 2) analyzing location from double writes I found out in _CopyFilesMarkedLocal section
Copying file from "\VenomousProject\bin\Debug\Newtonsoft.Json.dll" to "HostProject\bin\Debug\Newtonsoft.Json.dll".
That was it.

You can try MSBuild Binary and Structured Log Viewer (https://msbuildlog.com/)
build the project from command line with msbuild -bl - you will get msbuild.binlog
open the binlog with the log viewer and use the dll name as a search term
inspect all records related to the dll and backtrack a place (project and msbuild' target) where the wrong file version is taken.

With PackageReference, NuGet will write a file named project.assets.json in the project's obj folder. This file is used by the rest of the build to determine what files from packages should be included in the build, but it also contains a list of all the packages that were selected, what version was selected, and what dependencies each package has (package id and version). This is the closest thing to dependency resolving debugging that NuGet has.
In the file, search for "Newtonsoft.Json/, and you should find which version of Newtonsoft.Json that NuGet selected. Remove the / and replace it with ", and you can find all the packages that have dependencies on Newtonsoft.Josn. Search for newtonsoft.json.dll to find all the packages that ship that dll in its package (sometimes package authors perfer to ship multiple dlls in their package, rather than adding dependencies, which prevents NuGet from being able to version selection.
If there are multiple packages with which contain a dll with the same filename, NuGet will tell MSBuild about all of them, and it's up to MSBuild to select which one to use (pass to the compiler and copy to the bin/publish directory). As #Serg wrote in their answer, you can use binlogs (with the -bl argument on any MSBuild command, including dotnet restore or dotnet build). NuGet's inner workings are not output to MSBuild, so when your package graph has multiple packages that list Newtonsoft.Json as a dependency, it won't tell you why NuGet chose a specific version, but binlogs are very useful at debugging other build related issues.

Dependency error (System.Net.Http) when using Azure deployment options - works when publishing in Visual Studio

I have a very weird situation I hope someone can help with!
I have a normal ASP.NET MVC website. I've set up "Deployment Options" to push to a domain on every Develop commit. However, this has started giving the dependency error:
Could not load file or assembly 'System.Net.Http' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Now, I thought this was some caching since solution worked locally. So I have been publishing the app inside Visual Studio a couple of times (with option of deleting all remote files), and then the solution works.
However, after doing this, and I go back to a normal commit with Deployment Options, I go back to the same error:

From your description it seems like it has deployed successfully in past.
Have you upgraded project recently? If yes, look at this thread Strange issue with System.Net.Http 4.2.0.0 not found
Also, check if you are referencing DLL from NuGet and not GAC.

First thing that comes to mind is that you added a new DLL in your solution that depends on another version of System.Net.Http assembly. If you know that you added a new DLL, check for its assembly dependency.
Another solution might be to manually specify the version of the assembly in code. And select SpecificVersion. (but I'm guessing it's the first thing that causes the issue).

I have came across similar issue once. There should be a mismatch of the versions between System.Net.Http package.
Try verifying the version of System.Net.Http for the entire solution and refer the same version in all the projects.
This happens if a package is referenced in a project and different version of the same package is referenced in another project. Here, this error occurs when there is a reference between these two projects.

There was a conflict between "mscorlib, Version=4.0.0.0" and "mscorlib, Version=2.0.5.0" [duplicate]

On a new Win8.1 reinstall, with all of my code restored from backup, I'm suddenly now getting a Visual Studio warning when I build the main project of my solution:
Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
I set the Output log level to Detailed and I found a few entries like this:
There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it had a higher version.
Trouble is, I'm not referencing mscorlib anywhere in the solution—old or new. I have a couple of apps on my machine that require .NET 3.5, but I can't see how that could be related.
One difference: the old Win8.1 install on which this warning did NOT occur was a standalone machine; this time I'm domain-joined. I don't know whether that makes a difference (I can't see how), but I thought I ought to mention it at least.

Having different versions of a Nuget package on different projects may cause this problem as well. Make sure that all your packages have the same version:
(Within Visual Studio) Right click on the solution
Click on Manage Nuget packages for Solution
Click on the Consolidate tab
For every package in the Consolidate tab, update the package to the same version for every project.

I was able to fix this by issuing an update-package -reinstall command at the Package Manager Console.
BUT
Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong!

I have been able to fix this issue by deleting my ".suo" file of my solution and then re-opening the solution. I then rebuild the solution and the issue is gone.
The ".suo" file is within the ".vs" folder which is what I usually delete.
Good luck!

I solved this by setting my verbosity to Diagnostic as per this answer.
Once I did that and rebuilt my solution, the build log actually listed the specific packages that depend on the two different versions of mscorlib.
In my particular case, my project had references to version 2.0.20126.16343 of System.Net.Http. I opened up the NuGet Package Manager and updated this package to the latest version (4.3.4 at the time). The next time I built my solution, the warnings were gone.

Well my solution is a little bit simpler than all of the above. I simply added a reference to the two Assemblies throwing this error (System.Runtime.Serialization and mscorlib) and rebuilt the project. By doing this, I specified the 4.0.0.0 version and removed the ambiguity.
One of the two (mscorlib) couldn't be added via the GUI because of the "A reference to 'mscorlib' could not be added. This component is already automatically referenced by the build system." error.
I needed to open the .vbproj (.csproj) file and add a reference manually via:
<Reference Include="mscorlib" />

I've tried all the following, but none has resolved the issue.
the command "update-package -reinstall".
Update and package via Consolidate tab.
Removing the ".suo" file.
However, My issue was a different case, I guess the new version of Xamarin.Forms package has used a different version of mscorlib. so I've downgraded it and it works fine.
I suggest you try all above solutions and also try to find which package is conflicting.

Following Memet Olsen's advice using VS2017 community...almost identical:
Right click Solution in Solution Explorer.
Select 'Manage Nuget Packages for Solution'
Check the packages. If any of them have a blue up-arrow rather than a green tick use the 'update' button

I also have tried all of the proposed solution to no avail.
In my project, this warning message was caused by a dll reference having a dependency on a different .net framework than the one that is targeted by my project.
In order to find out which dll reference was causing the warning, I simply used .net reflector to explore each dll reference to find out which one was referring a different .net framework (mscorlib).
In order to fix the issue, the reference dll has to be updated to a version which targets the same .net framework as the project using it, if such a version exist.
Hope this helps.

Type definition exists in two libraries

I am building an ASP.NET Web Forms web site using .NET 4.5.
The error ...
The type 'System.ComponentModel.DataAnnotations.Schema.ForeignKeyAttribute' exists in both 'f:\Projects\web sites\RC1Iteration05\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll' and 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.ComponentModel.DataAnnotations.dll'
I have tried to alias the libraries using ...
csc /r:EF_DataAnnotations="f:\Projects\web sites\RC1Iteration05\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll" /r:CM_DataAnnotations="c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.ComponentModel.DataAnnotations.dll"
but this only resulted in "No Source File specified" which is equally confusing since the source files were specified as directed (here & here).
I did notice that the error was referencing the EF dll in the net40 folder rather than the net45 folder. I figure if I used the net45 version the problem would resolve itself, however I do not know how to change that reference. I changed the "targetFramework" attribute to the EntityFramework package in the packages.config file, but that did not make any difference.
I am a bit stuck since both of the solutions did not seem to do anything.
I looked around and found a number of posts here where folks have dealt with similar issues but have received no responses. I am hoping that there is someone out there who can help!
Thanks
G

As you noticed, you're using the .Net 4.0 version of Entity Framework on .Net 4.5.
That won't work.
Re-install EF from NuGet and it should work fine.

The other options didn't work for me. What did work was going into \packages\EntityFramework.6.1.3\lib\ and deleting the net40 directory and then doing a rebuild all.

"An assembly with the same simple name has already been imported" error without duplicate reference

I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.

So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.

In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.

In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.

If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps

I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.

For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.

For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)

In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.

Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project

In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.