Behavior change for RAR Copy Local behavior when in the GAC

[AndyGerlicher]

This change request came from an external connect bug. Note the change is only when the Private tag ('Copy Local' in Visual Studio) is not present, which is the default. If this flag is given by the user it will still be honored in all cases.

Current Resolve Assembly Reference (RAR) behavior

1. If the assembly is resolved and not found in the GAC, copy it.
2. If the assembly is resolved from the GAC, don't copy the DLL.
3. If the assembly is resolved locally and also happens to be present in the GAC, don't copy the DLL.

This behavior was intended to somewhat mimic run-time behavior. If an assembly is in the GAC on the build machine, it's assumed to be in the GAC on the target machine.

Proposed change in behavior

1. If the assembly is resolved locally (not in the GAC) copy it. Regardless of if it's in the GAC or not.
2. If the assembly is resolved through the GAC (wasn't found locally), then do not copy it.

Repro Steps

1. Project1 references Project2 (Project Reference type)
2. Project2 not in the GAC.
3. Build

This yields the desired behavior, Project2.dll appears in the output folder.

However, if this test is repeated with Project2 in the GAC, Project2.dll will not be copied. The proposed fix would change this behavior and copy Project2.dll (since it was resolved locally first). This should also help when NuGet packages are referenced but also in the GAC on the build machine.

[ajryan]

It appears that this change was made, but I don't see any indication of this in the release notes, and there aren't any commits linked here.

Is the "Proposed change in behavior" the actual VS2015 RTM behavior?

[AndyGerlicher]

Yes this is the behavior for RTM. We did this to make builds more deterministic across machines and to make servicing assemblies that might be in the GAC and referenced from NuGet more predictable. Hopefully it's an overall positive change.

It can be disabled and the behavior reverted by adding a property "DoNotCopyLocalIfInGac" to your project (or props file). We'll work on getting this documented on MSDN for the Resolve Assembly Reference task.

And now that VS2015 has shipped I'll be working on getting that fix (and others since the last snap) out to GitHub. Our intention is to make GitHub our primary source control location, but as you can see that hasn't happened quite yet.

[ajryan]

Thanks for the confirmation.

I only discovered the DoNotCopyLocalIfInGac by diffing the 12.0 to 14.0 targets files. This is a pretty significant change and I'm surprised there was no advance warning.

I would consider this a regression / breaking change for anyone who XCopy deploys from the build folder (which we do). Unless you get lucky and inspect the contents of your output folder, you may not realize that the size of the deployment package can increase a lot, and worse, the versions of assemblies bound at runtime on end-user machines can change.

[catester]

Andy, I understand the change but I think there are still some problems. Consider I have a reference like this in Project A:

    <Reference Include="System.Web.Mvc">
      <HintPath>..\References\System\System.Web.Mvc.dll</HintPath>
      <Private>False</Private>
    </Reference>

Note that there is a Private property explicitly set to false. However when I reference Project A in a web application named Project B (web-forms), System.Web.Mvc.dll and some related DLLs are unexpectedly copied to the bin folder.

Yes, I can fix it by adding this in Project B:

  <PropertyGroup>
    <!-- Fix the default copy local behaviour changed in VS 2015 -->
    <DoNotCopyLocalIfInGac>true</DoNotCopyLocalIfInGac>
  </PropertyGroup>

But I think I should not require this as I already have an explicit Private property. I guess there is a bug with this new behavior when using project-to-project references.

[franckyinuk]

We have recently moved to VS2017 and we are seing very bad build times, 2 to 3 times slower.
And maybe we are facing the issue above.

The problem is that for our overnight builds we are using nmake to build project with makefiles we generate.
Is there a way to use the option DoNotCopyLocalIfInGac in a makefile our as an option to nmake?

[deymundson]

@AndyGerlicher I was surprised to discover that there is no documentation on the DoNotCopyLocalIfInGac property on MSDN. The closest I could find was the answer to this question on StackOverflow
https://stackoverflow.com/questions/32647713/vs-2015-copies-to-output-gac-references-of-a-project-reference-regardless-of-cop
This ended up working for me because I have a project that was recently upgraded from VS2013 to VS2019. I would be more comfortable with some "official" doc that outlines how the property needs to be used rather than relying on here-say elsewhere on the internet.