Dependencies of references not copied to output directory

Question

I have a CommonUtils lib I have built into a dll which I file reference from several of my projects. CommonUtils depends on log4net.dll which was set as a file reference and copy-local=true when CommonUtils.dll was built. log4net.dll and CommonUtils.dll are not in GAC.

Everything works fine in MyWorkingProject where I only have a file reference to CommonUtils.dll - log4net.dll shows up in the output directory (as it is a dependency of CommonUtils.dll but not referenced from MyWorkingProject). However if I create a new project to add some unittests: MyWorkingProjectTest and project reference MyWorkingProject and then file reference CommonUtils.dll again here (I want to use some of the CommonUtils) then upon building log4net.dll which is a dependency in both the project reference and in the file reference as well does not get copied to the output directory.

Can anyone clarify what is happening here? Does the compiler not know which of the log4net.dll files it should grab? Is there something I am doing wrong here? Should I do this in some other way for the log4net.dll to get copied explicitly? Does it make any sense that I have to explicitly reference log4net does it?

Answer 1

I believe if you do not add log4net as a reference in your project it will not get copied.

Answer 2

When I've had a similar situation in the past, I received a compiler warning within Visual Studio telling me that I needed to add a reference to the dependent library.

Are you receiving such a warning when you compile? If so, follow the advice it gives and you should find Log4net copied to your output directory.

Answer 3

This is by design. You need to think about the implications that automatic inheritance of references would cause. While you can logically see what the references should be, there is no such delineation to the compiler. You could, theoretically, end up reproducing the Framework and a good part of your OS if it walked the entire dependency tree.

It definitely is a pain, and I agree with and understand your frustration, but I assume that Microsoft was not able to find a logical way to do this otherwise.