Assembly added via Add Reference not copied to output directory unless referred to in code

Question

Situation:

• Project 1 is an assembly in the solution
• Project 2 is an executable assembly project in the same solution
• Project 2 has a project reference (via Add Reference) to Project 1
• Project 2 does not directly refer to namespaces/types in Project 1 in the code
• Project 2 uses Ninject to dynamically load Project 1 and use the implementation classes within it

Problem:

• Even though Copy Local is set to True for the reference, and the referenced assembly does not exist in the GAC, the referenced assembly is not copied to the output build directory
• Ninject subsequently does not find the assembly, and so the binding/resolution fails

This process works fine for an identical setup where some classes in the referenced assembly are referenced directly, as well as loaded by Ninject, so I believe the cause is as follows: If VS detects that no types within a referenced assembly are referred to in code, it won't copy the referenced assembly, even if it's added as a reference with Copy Local = True.

Solution(s):

• Find a way of telling VS, "Copy Local (I really mean it)" = True -- this would be my ideal solution.
• Add a file reference to the referenced assembly. Not great since I lose the advantages of a project reference (which may or may not be entirely in my head).
• Refer to the assembly in some 'token' way in code. Messy - I'd like to use the References list to maintain a list of assemblies/modules I want to include.
• Post-build steps to copy the assembly around. Messy, not ideal.

Can anyone help with the first solution, or suggest another?

Cinthiacintron

If VS detects that no types within a referenced assembly are referred to in code, it won't copy the referenced assembly, even if it's added as a reference with Copy Local = True. I don't think that is the case. Creating a dummy solution that does exactly that includes the unused assembly in the bin. You may want to try building your solution with msbuild and set the verbosity to diagnostic to see exactly what is going on. – Cloris

You are right thanks, it was to do with framework versions (editions?) rather than whether it's used or not. Coincidence that in my test setup I had added 2, one used and one not, both almost identical, apart from framework 'edition'. – Cinthiacintron

Answer 1

Aha.. the referenced assembly targeted .NET Framework 4.0, but the referencing assembly was targeting the Client Profile version of .NET 4.0.

The reference was added, appeared, no problems or warnings at all (from the UI or VS at least), but I couldn't refer to it in code, and it wouldn't appear in the output.

If anyone has ideas why this went undetected, perhaps they could let me know?

Cinthiacintron

If youu look in the build output, there'll definitely be something - problem is it's only a warning (and you might need to get something to treat warnings as errors). MS are very bad about silent failures like this in spots e.g. if you remove a project from a sln it will go and build it with defualt properties and leave only the slightest clue when you turn MSBuild output level up to Detailed) – Planography

Answer 2

If you deploy/copy an application that contains a reference to a custom component that is registered in the GAC, the component will not be deployed/copied with the application, regardless of the Copy Local setting. See MSDN

You have to force copy local to true by adding Private metadata to the GAC assembly reference. Edit your project file and add Private metadata:

<Reference ..>
    <Private>True</Private>
</Reference ..>

<ProjectReference ..>
    <Private>True</Private>
</ProjectReference ..>

Now your GAC assembly should be copied/dropped from the output folder.

Tortile

Is it possibly to do this through Visual Studio? I don't want junior developers manually editing proj files. – Fontanez

No. Check properties on youor reference in VS – Tortile