Assembly in GAC is not copied to output in project that references a project that references the GAC assembly with CopyLocal=true

Question

I have a "Project A" that references System.Web.Mvc with CopyLocal=TRue. System.Web.Mvc is in the GAC both on my local maching and on the buildserver.

I also have a "Project B" that references "Project A" in the output for "Project B" System.Web.Mvc is not copied to during the build.

I suspect that this is because it is in the GAC. Is this true? And can I do something to make MSBuild copy it to the output folder?

I read the answer from Muse VsExtensions in this thread, which talks about only the direct reference to the GAC, however we have an indirect reference through "Project A": .NET Reference "Copy Local" True / False Being Set Based on Contents of GAC

This blogpost is also related: http://deeperdesign.wordpress.com/2010/02/08/msbuild-assembly-dependencies-and-the-gac/

Orpah

Interestingly, this appears to happen even if your project references a copy of the assembly that isn't in the GAC. VS sees that a copy lives in the GAC and won't copy it. – Fossick

The assumption is correct. Setting MSBuild verbosity to diagnostic gives This reference is not "CopyLocal" because it's registered in the GAC. when resolving dependencies. – Janise

Answer 1

One suggestion I've seen floating around for this one is to change all of your projects to have the same output path. This is of limited value though, since if you have a dependency chain like: Prj B > Prj A > Lib C Then it's probably because Prj A is shared across multiple applications, for which you will want to each have their own output path.

I resolved the issue by instead using MSBuild to compile, and setting the OutDir property on each build.

e.g. MSBuild projectB.csproj /p:OutDir=C:\AppBOutput\

This will put the output for project B, its dependent projects (prj A), and prj As copy local dependencies all into the C:\AppBOutput\ directory.

Why it Works

When building the project in Visual Studio, both prj A and prj B have their own output directory, e.g. prjA\bin\debug and prjB\bin\debug. The GAC-stored assembly set to copylocal will be included in the output directory of the project that directly references it (prjA). But it will not be copied to the output directory of the project referencing that project (prjB). That's just how the project reference copying works. Dig into the MSBuild targets and I'm sure the underlying reason could be found (sorry, not doing it myself).

What the /p:OutDir=C:\AppBOutput\ MSBuild parameter does, is set the output directory of all projects to be the same. By doing this, you side-step the MSBuild behaviour of how it copies project-to-project reference outputs. Instead of relying on MSBuild to copy some of the content in prjA\bin\debug to prjB\bin\debug, you just force all projects to output to the same directory.

Cle

It isn't clear how this would solve the problem. Setting all projects to output to the same directory does absolutely nothing in this case – Janise

I've received a couple of downvotes on this answer since @Al-Muhandis comment, so I've edited my answer to explain why this works. I've also re-tested the solution now 4-and-a-half years later! with VS2015 and MSBuild 14.0 and can verify it still behaves the same way. Given that MVC is now preferably referenced via NuGet, the point is kind of moot there, but the situation remains the same for other GAC-ed assemblies, e.g. System.Xml.dll. – Cle

Answer 2

Did you check the .csproj file to verify that the reference does indeed contain the <Private>True</Private> tag? Copy local is unfortunately has 3 states in the xml - True, False and ... missing.

Ketch

I actually added <Private>True</Private> to the csproj file of "Project B" where it references "Project A". But I still don't get System.Web.Mvc in the output folder. – Orpah

In "Project A" I already have <Private>True</Private> in the csproj file – Orpah

<Private>True</Private> doesn't help for that problem. – Campbellbannerman

Thank you. This did solve my problem. I had an Azure Worker Role project for which the packaged deployment file was missing some referenced DLLs. These DLLs were in the GAC on my local machine for other reasons (but won't be in the GAC on Azure). Even though the project reference had Copy Local, opening the project file in Notepad showed the private tag was missing for each DLL. I changed the Copy Local property to false, saved the project, then back to true and saved again. This was enough to get the missing private tags inserted into the .csproj project file xml and into Azure correctly. – Smalley

Answer 3

A pragmatic (read hack) solution is that I referenced System.Web.Mvc.dll in "Project B". This is definitively not the right solution, so please bring me a better solution :-)

Orpah

take my upvote. that's how i'm handling this crap since ages. – Campbellbannerman

Hi khebbie, did you find any solution for this? – Dicephalous

this is a better solution than the one marked as answer – Scepter