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.

C# Release build can't load SQLite.Interop.dll

I'm building a c# program that uses a local SQLite database to manage some simple data.
I am using the NuGet System.Data.SQLite (x64/x86) v1.0.98.0 - downloaded using the package manager console in Visual Studio Community 2015. Windows 7 64-bit.
I've built and debugged my code using the "Any CPU", x64, and x86 settings and it works fine. After I publish any of these versions though, I get the following error:
An unhandled exception of type 'System.DllNotFoundException' occurred in System.Data.SQLite.dll
Additional information: Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The error occurs here:
SQLiteConnection.CreateFile("local-db.sqlite");
sqlite = new SQLiteConnection("Data Source=local-db.sqlite;Version=3;"); //Error on this line
Suggestions that haven't worked:
copying the bin/debug/x64 (and x86) folders (They contain versions of Interop.dll) up one directory
add SQLite.Interop.dll as a project reference (error - can't add as a reference)
add to project as existing item, set property "Copy to output directory = always". (still gets original error)
copying the most recent version of Interop.dll to the System.Data.SQLite directory (the directory referenced by my project)
At the very least, it's not failing to load the .dll but failing to find it. I don't know my way around dll's but it might work if I know where it's looking. Does anyone have a fix for this? There are a handful of related questions but they are either unanswered or don't work for me.

Why the compilation error from Team City after adding Newtonsoft.Json?

I have a service that was sending bad DateTime data due to use of the JavascriptSerializer. I used Nuget to add Newtonsoft to the project, and utilized that. Here's the only place it's utilized in the code (old way, then new):
374
- var messageString = new JavaScriptSerializer().Serialize(messageDetails);
374
+ var messageString = Newtonsoft.Json.JsonConvert.SerializeObject(messageDetails);
Below is an error that occurs during the Team City build:
Consumer\MetricTrackingMQServiceConsumer.cs(374, 49): error CS0122: 'Newtonsoft.Json.JsonConvert' is inaccessible due to its protection level
Consumer\MetricTrackingMQServiceConsumer.cs(374, 61): error CS0117: 'Newtonsoft.Json.JsonConvert' does not contain a definition for 'SerializeObject'
The project compiles fine locally. Why is it failing in Team City?

As you're using NuGet to include the dependency here's the workflow I strongly suggest to avoid these type of issues.
Ensure that your reference to the Newtonsoft DLL is pointing at the NuGet packages folder.
Exclude the NuGet packages from source control.
Add a "Nuget Installer" type build step before your solution build step to restore all the NuGet packages referenced by the solution.
This has a number of advantages but most importantly given your current issue, it ensures that the version of the DLL referenced by your solution is available and in the correct location.

The following steps fixed this for me:
On your nuget installer step in your build: You may need to "Disable looking up packages from local machine cache"
Uninstall the newtonsoft reference via nuget in your project. Open the csproj file in a text editor and manually delete any remaining references to newtonsoft in there. Save the csproj file, reload your project
Reinstall newtonsoft via nuget
post your changes to your repository (git or whatever you have)
Rerun the teamcity build

VS 2010: C# Project Cannot Open DLL

I'm having an issue building a project that references a DLL located in the project's bin folder, which up until yesterday was building and running without issue.
The error I'm getting is fatal error CS0009: Metadata file 'c:\MyProject\bin\myClient.dll' could not be opened -- 'Error importing module 'myClient.netmodule' of assembly 'c:\MyProject\bin\myClient.dll' -- The system cannot find the file specified.' Intellisense is similarly complaining that The type or namespace 'Api' does not exist in the namespace 'Client' since it can't find the DLL.
Let me know if you think this is a duplicate, but I've viewed several similar posts and the solutions did solve my problem. Here are some examples:
Visual Studio 2010 — are you missing a using directive or an assembly reference?
VS2010 - Getting “type or namespace name could not be found” but everything seems ok?
Stymied by ASP.NET Compilation Error CS0009
Metadata file '…\Release\project.dll' could not be found in Visual Studio
Visual Studio 2010: Metadata file “…/Debug/Graph.dll” could not be found
Metadata file … could not be found error when building projects
Specifically, I've tried the following solutions (and combinations of these):
Cleaned and rebuilt my project.
Made sure that the target framework is not a 'client profile' version of .NET
Verifyied that the dll has been added as a project reference
Removed and re-added the project reference
Verified that the project is showing the DLL in the References section in Visual Studio
Repaired .NET
Verified the location of the DLL (it is in the local project's bin folder as given by the error)
Tried other versions of .NET
Closed and restarted Visual Studio
Rebooted my machine
Verified there are no hidden characters surrounding the 'using' statement
Removed all code changes since the last working build
Verified the settings in Configuration manager, including that 'Build' is checked
The project calling the DLL is a small class library that resides in a solution with one other small project (a console application). The DLL is an external DLL that I've been using successfully for several weeks in this project/solution. The error arises regardless of whether I build the project from the solution or by itself.
Any ideas about what could be going on?

Have you included bin folder in your project accidentally? If yes that might cause the issue. You can't include bin folder in your project as the bin folder will be created by the VS. If you accidentally include bin folder in your project, the bin project will be set to Copy to output which when you compile, the file is deleted and copied to output by Visual Studio that trigger weird behavior that some file is missing.
Hopes this help

Well I'm not sure exactly what happened here, but here is what finally resolved the issue:
A good-old-fashioned delete every single file and rebuild the project from those files from scratch. I gave +1 to some of the responses because they were useful to consider, and because there was probably a messed-up reference some where as Jonathon Wood suggested.

"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.