Behavior change for RAR Copy Local behavior when in the GAC about msbuild

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