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?
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?