Why are C# references added differently between NuGet and Visual Studio

Question

We use NuGet (NuGet Version: 3.5.0.1996) two different ways. Either we run it from the command line or we use the NuGet Package Manager in Visual Studio (2015).

The problem is that these two ways add references to the.csproj file with different formats. If we use the command line, we get a reference that looks like this:

<Reference Include="Dummy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
  <HintPath>..\packages\Dummy.1.27.10\lib\net452\Dummy.dll</HintPath>
  <Private>True</Private>
</Reference>

If we use the NuGet Package Manager in Visual Studio, we get a reference that looks like this:

<Reference Include="Dummy, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
  <HintPath>..\packages\Dummy.1.27.10\lib\net452\Dummy.dll</HintPath>
  <Private>True</Private>
</Reference>

Notice that ones adds the reference with the PublicKeyToken attribute and the other adds it with the processorArchitecture attribute.

This causes issues with our source control with frequent (and unnecessary) updates and merges.

It would be nice to know why this happens, but I would much rather have a way to prevent it from happening. Any suggestions?

Answer 1

Starting with Visual Studio 2015, Nuget comes embedded and you cannot change the version used. I don't have a VS 2015 at hand to check, but most likely it is using a version different than the one you have in the command line.

Nuget has "suffered" (or enjoyed) a lot of changes and I think this is just a manifestation on how two different versions of nuget handles package references.

My suggestion, to avoid having issues with source control, is to standardize one way of using Nuget and stick to it. My suggestion would be to use it inside Visual Studio, either by means of Package Manager Console (similar to the CLI) or though the visual interface.

Answer 2

I made a little research. And decide to post an answer.

PublicKeyToken = null gives you information about that CLR is looking for the unsigned assembly.

• What is the assembly in .net?

Assemblies form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions for a .NET-based application. Assemblies take the form of an executable (.exe) file or (in this case) dynamic link library (.dll) file , and are the building blocks of the .NET Framework.

• What is public key token?

The public key token is a small number which is a convenient "token" representing a public key. Public keys are quite long; the purpose of the public key token is to let you refer to keys without saying the whole key. Sort of the same way saying "The Lord of the Rings" is five words which represent a half-a-million-word novel. It would be rather inconvenient if every time you wanted to talk about it, you had to state those half-a-million words.

When we know the definitions for assemblies and public key tokens, we can speak about them.

When you add references to your project, they look different.

• Why? What could cause the difference?

Add a file reference. The initial value of Specific Version in Properties panel is False. The csproj file look like

<Reference Include="Name">
  <HintPath>...</HintPath>
</Reference>

Change Specific Version in Properties pane to True. VS adds version in the Include attribute.

<Reference Include="Name, Version=...">
  <HintPath>...</HintPath>
</Reference>

Change Specific Version in Properties pane to False again. VS adds a child element SpecificVersion.

<Reference Include="Name, Version=...">
  <HintPath>...</HintPath>
  <SpecificVersion>False</SpecificVersion>
</Reference>

So the final definition seems to be:

Which reference-type you get depends on how you link the assembly.

Your issues comes from incompatible assemblies. Not from the way how you references them.