Friday, October 19, 2012

Incorrect “Copy Local” value upon checkout from the source control repository

The “Copy Local” setting of your referenced assemblies is stored in the *.csproj file. Take a look at this example fragment:

<Reference Include="Foo.Bar.Qux">
  <HintPath>..\Foo.Bar.Qux.dll</HintPath>
  <Private>True</Private>
</Reference>

This particular fragment of a *.csproj defines the reference to the Foo.Bar.Qux.dll which could be found in a particular location but also has the Copy Local set to True (note that “Copy Local” is referenced here as “Private”).

The issue we have observed is that when you just add references to your assemblies, Visual Studio deduces the value of the “Copy Local” somehow (how?) but doesn’t necessarily persist this “deduction” as a particular value of the “Private”. The “Private” is just missing and the project file says just that:

<Reference Include="Foo.Bar.Qux">
   <HintPath>..\Foo.Bar.Qux.dll</HintPath>
</Reference>

And then comes the issue we have observed.

You see, if you check out your code from the repository to another machine, most of the times the Copy Local will have the correct value – this still unidentified “deduction” will return the same value even though the explicit value is missing from the project file.

And then someday you checkout your code somewhere just to find out that 19 of 20 references has correct values but one of them (it is not “special” in any way!) has not (this happened to us)!

The solution to this unexpected issue is not to rely on the default deduction but always CLICK the value in VS Properties window once or twice to set it to expected value. When you click it in VS, the

<Private>True</Private>

or

<Private>False</Private>

is always added to the project file and then there is no need for any deduction as the explicit value is available.

1 comment:

Paul Markham said...

It might be because on the 1 out of 20 case, the user has the DLL in their GAC.