"Where Is This Reference Coming From"

Question

This is something that is bothering me.... Possibly unnecessarily so but still. I don't like mysterious things happening in Visual Studio that I cannot explain.

So here goes. I have a Solution with 42 projects in it with various interdependencies.

In this solution I use a number of NuGet packages. One example would be Microsoft.Identity.Client

At the moment I am the latest officially released NuGet package for this, which is 4.26.0. This NuGet package is installed against 3 of the Projects out of the 42.

None of the projects have any other reference to Microsoft.Identity.Client. Neither NuGet nor a reference to some DLL or other.

Now here's the mystery. When I build the entire solution, the builder for the main program reports:

42>  No way to resolve conflict between "Microsoft.Identity.Client, Version=4.21.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae" and "Microsoft.Identity.Client, Version=4.14.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae". Choosing "Microsoft.Identity.Client, Version=4.21.1.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae" arbitrarily.
42>  Consider app.config remapping of assembly "Microsoft.Identity.Client, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae" from Version "4.21.1.0" [] to Version "4.26.0.0" [C:\Users\Pino\.nuget\packages\microsoft.identity.client\4.26.0\lib\net461\Microsoft.Identity.Client.dll] to solve conflict and get rid of warning.

I know I can easily get rid of these warnings. Simply adding this to my config file does that:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Identity.Client" publicKeyToken="0a613f4dd989e8ae" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.26.0.0" newVersion="4.26.0.0" />
  </dependentAssembly>

But what bothers me is that I explicitly installed the NuGet package for Microsoft.Identity.Client 4.26.0.0 to that project. So why is it picking up references to versions 4.21.1.0 and 4.14.0.0? I imagine that it retrieves these by looking at dependencies of other things it references? So my question is:

How do I find out what causes these references to be pulled in? Is there a way I can retrieve an implicit dependency list and what causes each DLL to be included therein?

Answer 1

This is all logged in the build log but you have to turn on detailed or diagnostic logging to see it. In the options under Build set the output to one of these and then rebuild. You'll have to wade through lots of output but searching by the assembly name will jump you to the places in the log where an assembly is being added as a reference and what other reference caused it to show up.

Note that if you have a Dependencies node in your projects (using the new SDK format) then you can also click on each of the dependencies and view their dependents to work your way down to the cause.

Irrelevant of the cause though this is a valid warning. It is not a false positive. Your project is referencing something that is only coded to work with an older version of something that your project is trying to use a newer version of. This potentially could break something. Furthermore the order in which dependencies are copied into the output directory is pretty much undefined so it is possible you may end up using the older version of the dependency even though your project (or somebody else) requires a newer one. The binding redirect is going to help here but adding a direct reference helps ensure the newest binary is used. It is a necessary evil in the package days.