42

Project A references Project B, and Project B references an external DDL (restored using NuGet). The DLL should get copied into Project A's bin folder (along with Project B's DLL):

DLL References Copied To Bin

In my case, when running Project A, I get the following exception thrown:

Could not load file or assembly 'PostSharp, Version=3.2.18.0, Culture=neutral, PublicKeyToken=b13fd38b8f9c99d7' or one of its dependencies. The system cannot find the file specified.

The DLL is not being copied into Project A's bin. All other external references from Project B are being copied across just fine, which is what is confusing for me.

Copy Local is set to true for all references involved. Example:

Copy Local Reference

How do I do this?

Note: Using Visual Studio 2013.

Dave New
  • 34,265
  • 48
  • 183
  • 366
  • possible duplicate of [Msbuild doesn't copy references (dlls) if using project dependencies in solution](http://stackoverflow.com/questions/1132243/msbuild-doesnt-copy-references-dlls-if-using-project-dependencies-in-solution) – Bobson May 08 '14 at 14:53
  • Actually, a better answer would be http://stackoverflow.com/questions/1043913/copying-a-dlls-dependencies-in-visual-studio?lq=1 – Bobson May 08 '14 at 14:55
  • 12
    I think this is an example of a well asked question :) – Mike May 08 '14 at 16:37

3 Answers3

21

The options that I found were to:

  • Add a reference to PostSharp in Project A.
  • Add dummy code in Project B so that the compiler would detect that the reference is being used.
  • Add a build event to force copy the DLL.

I don't like any of the above solutions. They are hacks in my opinion and will only make for a more unmaintainable solution in the long run.

I have fixed the problem by using a common output directory. This seems to be a recommended solution by many. I have also experienced much faster build times. See this Stackoverflow post.

Community
  • 1
  • 1
Dave New
  • 34,265
  • 48
  • 183
  • 366
  • 4
    I also found the dll needed to be using the same version of the .net framework – majjam Mar 14 '16 at 14:40
  • In my case, one project used the Client profile rather than full version of .net framework 4. Changing to the full version fixed the issue. – pilsdumps Dec 09 '16 at 09:56
0

When I ran into this problem it was because I changed a project's name, but did not change the assembly name - it was identical to the assembly name of another project in the solution.

Little Endian
  • 726
  • 5
  • 18
0

I've added some dummy (unused) code on Project B, making reference to the DLL needed.

Thus, the compiler will guess that it must copy the DLL into project A output.

user10642724
  • 1