Is "Copy Local" transitive for project references?

Question

Wrt. the proposed dupe: Since this here queston suggests the opposite of the linked question, I'd rather like to think it is not a dupe.

First, I did read What is the best practice for “Copy Local” and with project references? (also this) and I'll have to try this out anyway, but getting general feedback on this seems necessary as the docs on this stuff are horrible and I'm only on VS2010 and maybe they changed something in newer versions that'll be nice to know.

Second, I'm only interested in project references for this question as I've read that assemblies from the GAC are handled differently and the GAC is irrelevant for my problem.

Third, after reading the suggested dupe, but more so the nice answer here by @Albireo, it would also appear that it is important to differentiate file dependencies, where the dependency references a dll assembly file and project dependencies (i.e. what I'm asking about), where the dependency references a project and implicitly the output file of that project.

Anyway, here's the situation, somewhat peculiar I think, but still:

• 2 C# executable projects
• n C# dll assembly projects
• The 2 executables have different output directories as they will be deployed separately and that way they're also separate on the developer machine
• The 2 executables have dependencies on some of the DLL assemblies (which may depend on each other)
• There are three output directories:
  • /x1 for executable 1 project
  • /x2 for executable 2 project
  • /lib for all the dll assemblies

The DLL assemblies all have Copy Localset to false for their project references, as they all build to the same output directory.

The 2 executable projects have set Copy Local to true for all the DLL assembly project references they reference directly, so that the DLLs will be copied into /x1 /x2 respectively.

The question now is wrt. to DLLs that are not directly referenced by an executable project, but only transitively through a referenced assembly: Will assemblies, that are only referenced transitively through another assembly, be copied into the output folder of the executable, when "Copy Local" is set to true on the first assembly?

Example:

• x1.csproj (e.g.Output = x1/one.exe)
  • Reference: dlA.csproj ( e.g. Output = lib/a.dll) with Copy Local = *true*
  • (no direct reference on b.dll)
• dlA.csproj ( e.g. Output = lib/a.dll)
  • Reference: dlB.csproj ( e.g. Output = lib/b.dll) with Copy Local = **false**
  • (no direct reference on c.dll)
• dlC.csproj ( e.g. Output = lib/c.dll)
  • (no further relevant references)

Thus, we have a logical dependency of one.exe -> a.dll -> b.dll -> c.dll, where only a.dll with obviously be copied to the output directory of one.exe. Will the other two dlls also be copied to the output directory? Is this documented somewhere?

---

And, yes, I tried it. And, yes, it seems to work, but I haven't poked it hard enough yet and anyway there maybe something more to it that I may have missed. (And also there's the question wrt. any official docs.)

Camarena

possible duplicate of Visual studio not copying content files from indirectly referenced project – Pelion

@Pelion - from your proposed dupe: "All project references have CopyLocal = true." ... I do not have this. So it can't be a dupe question? – Camarena

I hit the same problem using AutoMapper, which uses a satellite assembly for .NET 4 code. AutoMapper was referenced in a Class Library project, and when building our Web Application the satellite assembly was never copied unless we used some of its code in our Class Library project. – Pelion

The problem lies in how Visual Studio computes the dependency graph, the Copy Local setting has no effect on this problem. Back when I hit this problem I found a detailed post explaining the issue, but I can't find it at the moment, that question is the closer thing I could find. – Pelion

Hmm ... there is a ResolveAssemblyReference Task documented. Maybe looking further into that can shed some light on this ... – Camarena

Answer 1

it would also appear that it is important to differentiate file dependencies, where the dependency references a dll assembly file and project dependencies (i.e. what I'm asking about), where the dependency references a project and implicitly the output file of that project.

Not really, no.

MSBuild doesn't really care if the reference points to another project in the solution or to a DLL.

If ProjectA depends on ProjectB to build ProjectA ProjectB must be already built (and up-to-date), MSBuild will then pull its DLL (not its C# code) and link it to ProjectA.

Adding a project reference instead of a DLL is "syntactic sugar" for your convenience: this way MSBuild knows it must pick the output of the referenced project, whatever the output is.

Otherwise, you'll have to manually pre-build the dependency, find its DLL and link it to the project, repeating the process whenever you switch build configuration, move or rename things. Not really practical.

Will the other two dlls also be copied to the output directory?

If any kind of element from a dependency is used directly from the project where the assembly is referenced, that reference will be copied.

An example could be this solution layout:

• MySolution
• MySolution.ConsoleApplication
• MySolution.FirstDependency
• MySolution.SecondDependency
• MySolution.ThirdDependency
• MySolution.FourthDependency

With this dependency chain:

• MySolution.ConsoleApplication
• MySolution.FirstDependency
  • MySolution.SecondDependency
    • MySolution.ThirdDependency
    • MySolution.FourthDependency

If you build this solution you'll notice that in MySolution.ConsoleApplication output directory there will be the DLLs for MySolution.FirstDependency, MySolution.SecondDependency and MySolution.ThirdDependency but no DLL for MySolution.FourthDependency.

Why is it so? When MSBuild builds MySolution.SecondDependency it notices that there's a dependency declared to MySolution.FourthDependency, but since it can't find any usage of any kind of element from MySolution.FourthDependency in MySolution.SecondDependency code it decides to perform some "optimization" and omits MySolution.FourthDependency assembly from the output.

This same issue bit me in the past when I added through NuGet AutoMapper to a "deep dependency": adding AutoMapper adds two assembly references, AutoMapper and AutoMapper.Net4, where the second assembly is loaded by the first through reflection when it needs to perform certain kind of action on the new collection objects introduced by the .NET Framework 4. Since the second assembly is loaded through reflection MSBuild thinks it's unused and doesn't bother to copy it around.

So, yes, they will be copied as long as you're using them directly and not through reflection.

Is this documented somewhere?

This behavior seems to be a "feature" of MSBuild, I managed to find a blog post by some folks from Microsoft back when I experienced this issue, but I can't find it again at the moment.

Pelion

I know it's a little cloudy, if anyone more skilled feels like to clear up my explanation, feel free to do so. – Pelion

Your answer is very much appreciated. Thanks! However, I do not that you problem with Automapper was for an assembly file dependency, while my question is about assembly project dependency. They are different in msbuild. I'll add that to the question. – Camarena

Thanks a lot. I took the liberty to highlight the points that made me accept the answer – Camarena

What would be a solution in case of IoC? I have the same problem, and solving it by adding a dumb section of usage is...well dumb by it self. – Redbud

@nocgod IoC should have nothing to do with this problem unless you're dynamically loading assemblies, because the layer where your IoC container is located should have a direct reference to everything it's able to inject. However, the only two ways I'm aware of to address this problem are a fake usage or a manual XCOPY in the post-build events. – Pelion

@Pelion Could you take a look at my question? #26828053 – Redbud

Answer 2

It is very straight forward, doesn't have anything to do with Copy Local. MSBuild looks in the metadata of an assembly to see what the dependencies are for an assembly. So can you, run ildasm.exe on the assembly and double-click the Manifest. Be sure to try this to get insight. You'll see the .assembly directives. Inserted by the compiler when it built the assembly, only the referenced assemblies you actually used in your code will be listed.

If MSBuild can find such an assembly in the same directory then it will automatically copy it. If not then it will silently skip the copy.

From this, you can deduce the failure modes. It cannot copy unmanaged DLLs, they do not appear in the metadata. It cannot copy assemblies that you have an indirect dependency on through Assembly.Load/From(), they don't appear in the metadata either. It cannot copy assemblies that haven't been built yet, a build order problem. And it cannot copy assemblies whose Copy Local property you set to False. Which is normally only a valid choice if the assembly is present in the GAC, no copy required.

For such cases you need to help, XCOPY in a post-build event gets the job done.

Broek

"And it cannot copy assemblies whose Copy Local property you set to False." ... but this hasn't got anything to to with the metadata? – Camarena

No, that invokes the "it will silently skip the copy" clause. I knows the dependency from the metadata but the file isn't there. – Broek

BTW—Unmanaged DLLs could be part of the assembly, in which case they would be referenced in the metadata (MSIL .file). Aside from the GAC tools, support for copying such assemblies is sketchy. – Sulfatize

Thanks for the .manifest linking/copying insight! Makes sense now why we need to add some uncalled code to use a specific type! – Crumley

I have a project (let's call it Q) that contains a NuGet reference to CacheCow.Client.RedisCacheStore. This package in turn depends on CacheCow.Client, which depends on CacheCow.Common. The output for Q contains all 3 CacheCow DLLs. However, when another project (say, R) references project Q, it only gets the top-level RedisCacheStore. Is this related to this optimization? Do you know if there is a way to get the build of R to "recurse" into RedisCacheStore's dependencies and include them? I don't want to need to have R reference CacheCow directly, since it doesn't directly use it itself. – Yila

@HansPassant : Let say my ProjectA has dependency on ProjectB which refers to some myassembly.dll . So per your answer, MSBuild first build ProjectB with reference to myassembly.dll. Next it will build ProjectA and since it depends on ProjectB, it will first copy projectB.dll and myassembly.dll to o/p directory ? Lets say projectA also refers to myassembly.dll - so since it is already copied, msbuild will skip to copy and overwrite or will totally skip to copy ? – Heavyarmed

"If MSBuild can find such an assembly in the same directory then it will automatically copy it. If not then it will silently skip the copy" Not for me. It is looking in various places to try to find it, for instance from here C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\System.Runtime.CompilerServices.Unsafe.dll, but it checks other folders too. If it does not find indirectly references assemblies in any of these known folders, it will skip it.But the behaviour is very confusing and bug prone (and not deterministic). I have had a ton of problems with this. – Tippett