MSBuild doesn't copy references (DLL files) if using project dependencies in solution

user_57737 0
Viewed 169167

I have four projects in my Visual Studio solution (everyone targeting .NET 3.5) - for my problem only these two are important:

  1. MyBaseProject <- this class library references a third-party DLL file (elmah.dll)
  2. MyWebProject1 <- this web application project has a reference to MyBaseProject

I added the elmah.dll reference to MyBaseProject in Visual studio 2008 by clicking "Add reference..." → "Browse" tab → selecting the "elmah.dll".

The Properties of the Elmah Reference are as follows:

  • Aliases - global
  • Copy local - true
  • Culture -
  • Description - Error Logging Modules and Handlers (ELMAH) for ASP.NET
  • File Type - Assembly
  • Path - D:\webs\otherfolder\_myPath\__tools\elmah\Elmah.dll
  • Resolved - True
  • Runtime version - v2.0.50727
  • Specified version - false
  • Strong Name - false
  • Version - 1.0.11211.0

In MyWebProject1 I added the reference to Project MyBaseProject by: "Add reference..." → "Projects" tab → selecting the "MyBaseProject". The Properties of this reference are the same except the following members:

  • Description -
  • Path - D:\webs\CMS\MyBaseProject\bin\Debug\MyBaseProject.dll
  • Version - 1.0.0.0

If I run the build in Visual Studio the elmah.dll file is copied to my MyWebProject1's bin directory, along with MyBaseProject.dll!

However if I clean and run MSBuild for the solution (via D:\webs\CMS> C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe /t:ReBuild /p:Configuration=Debug MyProject.sln) the elmah.dll is missing in MyWebProject1's bin directory - although the build itself contains no warning or errors!

I already made sure that the .csproj of MyBaseProject contains the private element with the value "true" (that should be an alias for "copy local" in Visual Studio):

<Reference Include="Elmah, Version=1.0.11211.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\mypath\__tools\elmah\Elmah.dll</HintPath>
    **<Private>true</Private>**
</Reference>

(The private tag didn't appear in the .csproj's xml by default, although Visual Studio said "copy local" true. I switched "copy local" to false - saved - and set it back to true again - save!)

What is wrong with MSBuild? How do I get the (elmah.dll) reference copied to MyWebProject1's bin?

I do NOT want to add a postbuild copy action to every project's postbuild command! (Imagine I would have many projects depend on MyBaseProject!)

dependencies project visual-studio msbuild reference
20 Answers

If you are not using the assembly directly in code then Visual Studio whilst trying to be helpful detects that it is not used and doesn't include it in the output. I'm not sure why you are seeing different behaviour between Visual Studio and MSBuild. You could try setting the build output to diagnostic for both and compare the results see where it diverges.

As for your elmah.dll reference if you are not referencing it directly in code you could add it as an item to your project and set the Build Action to Content and the Copy to Output Directory to Always.

John_Hunter_22530

Take a look at:

This MSBuild forum thread I started

You will find my temporary solution / workaround there!

(MyBaseProject needs some code that is referencing some classes (whatever) from the elmah.dll for elmah.dll being copied to MyWebProject1's bin!)

user_577370
user_10772280

Make sure that both projects are in the same .net version also check copy local property but this should be true as default

user_80828860

Using Visual Studio 2015 adding the additional parameter

/deployonbuild=false

to the msbuild command line fixed the issue.

user_4109280

I dont think @deadlydog answer is valid with the current Nuget system. I recreated the scenario with Y => X => A => B in visual studio 2022 and all I had to do was run the command in terminal

msbuild -t:clean,rebuild,pack
user_25358090

Including all referenced DLL files from your projectreferences in the Website project is not always a good idea, especially when you're using dependency injection: your web project just want to add a reference to the interface DLL file/project, not any concrete implementation DLL file.

Because if you add a reference directly to an implementation DLL file/project, you can't prevent your developer from calling a "new" on concrete classes of the implementation DLL file/project instead of via the interface. It's also you've stated a "hardcode" in your website to use the implementation.

user_17729520
Related