15

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/

Community
  • 1
  • 1
khebbie
  • 2,490
  • 3
  • 31
  • 53
  • 1
    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. – mhenry1384 Oct 31 '12 at 15:15
  • 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. – makhdumi Jul 11 '16 at 16:22

3 Answers3

8

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.

RasmusKL
  • 891
  • 4
  • 16
  • I actually added True 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. – khebbie Nov 24 '11 at 12:10
  • In "Project A" I already have True in the csproj file – khebbie Nov 24 '11 at 12:11
  • True doesn't help for that problem. – stmax Oct 15 '14 at 14:30
  • 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. – cbailiss Feb 21 '15 at 08:37
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 :-)

khebbie
  • 2,490
  • 3
  • 31
  • 53
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.

Snixtor
  • 4,239
  • 2
  • 31
  • 54
  • 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 – makhdumi Jul 11 '16 at 16:21
  • 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. – Snixtor Jul 21 '16 at 02:01