Reference DLL file not copying to bin with deployment project, causing error

Question

We have several external DLL files being referenced in our Web Application Project. We have a deployment project for installing on the hosting servers. When we were using .N

Answer 1

I didn't meet the same problem but similar. I had WPF main project and referenced project where the referenced did not copy. I found that in my case the main project was set for NET 4.0 Client Profile and the referenced for NET 3.5. When I set the main project to 3.5 the compiled dll of the referenced project started to copy. (I don't know why because I solved it by practice)

Answer 2

I too ran into a similar issue where referenced dlls were not copied into the bin in published folder. I was using a TFS checked out copy that didn't include the bin folder into the application. -> So just included the bin folder. -> Built the referenced applications -> Published the website project Now I see all the referenced dlls in bin in the published folder

Answer 3

I had a similar issue with VS 2012 Express. I used Tesseract libraries in my project. Everything worked well until I used this project in a solution where were more than one project. Problem was that some DLLs (liblept168.dll, libtesseract302.dll) that are normally placed in folders bin/debug/x86 or bin/debug/x64 were copied only when I rebuilt whole solution. Changing a single line and building it again caused that the DLLs were deleted and not copied back.

I solved this issue by adding a reference of the project that creates missing DLLs to the startup project.

Answer 4

rzen and others, thanks - your comments led to a solution for us.

We have a project that targets version 10 of the Microsoft.ReportViewer.Common.dll and Microsoft.ReportViewer.WebForms.dll assemblies (separate "libs" folder we created at the 'src' level). But when we did a build, the output included version 12, which was recently installed on the build server.

Using comments here, we ensured that 'Copy Local' was set to True and that the flag was set in the project file. However, it was still deploying version 12. So what we found that did the trick was ensuring that the 'Specific Version' property was also set on the two references. Voila, version 10 of each file is now being deployed!

There was much rejoicing.

JH

Answer 5

Check the framework of the project in which the DLL file has been referenced. The framework should be .NET 4.0. Please correct it if the framework is Client Profile.

Answer 6

There is a bug in Visual Studio 2010. By default the XML in the solution file looks like this:

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>

Whereas MSBuild is expecting this below, so that the DLL file will be included in the deployment:

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>

The trick is to set Copy Local to False, save the project and then reset it to True - save again. This includes the Private node correctly, which MSBuild respects.

It appears that the default for no included private node (Copy Local) in Visual Studio 2010 is True, while MSBuild reads that missing node as False.