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 .NET 3.5 and Visual Studio 2008 the DLL files were being copied to the bin folder. Since we have upgraded to .NET 4 and Visual Studio 2010 this no longer happens, and we are getting server errors since the references cannot be found.

CopyLocal is set to true, and I cannot find anything inside the web.config which suggests this is being set elsewhere.

Solution 1

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.

Solution 2

I was getting the same problem and rather than add a "BeforeBuild" step I created a test that simply did this

    [TestMethod]
    public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
    {
        Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
    }

And that fixed the error The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler...' cannot be resolved

Solution 3

Something weird had happened to my deployment project. When I saw it had no detected dependencies, I removed the primary output and re-added it.

The dependencies are now showing up and being placed in the bin folder when installed.

Solution 4

I just had the same issue and wanted to share what I found as it might help someone:

The reason in my case was that the assembly was installed in the GAC during an installation of some third-party application.

If the DLL file is in the GAC, the compiler won't bother to copy it to the destination folder, unless you specifically mark it for "copy local" using the "Private" node in the project file as mentioned by Junto.

The thing is that if you don't add that node, and you develop on one machine and build on a different one, and the DLL file is only in the GAC of the build machine, the default behavior without the private node will cause the file to be copied correctly on the development machine, but not on the build machine.

The bigger problem is if the DLL file is not referenced directly, but the project references a second project that in turn references the DLL file. In that case, you cannot mark the DLL file to be "copy local" in the project, as it is not referenced by it. So if the DLL file exists in the GAC - it won't get copied to your output folder.

Possible solutions to this case are:

• Uninstall the DLL file from the GAC
• Add a direct reference to the DLL file in the end project(s)
• Re-sign the DLL file with a new strong name, which will differentiate it from the DLL file in the GAC.

Solution 5

I was getting exactly the same issue. We have a Visual Studio 2008 project which references the EnterpriseLibrary. When we run our integrated build using TFS and our Web deployment project, all the DLL files are copied over. When we upgraded to Visual Studio 2010, TFS 2010 and WDP 2010, some of the DLL file's were missing. Strangely, this only occurs to some DLL files and not others.

For example, we get the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll copied in both cases, but not the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.

As a workaround I copied the files accross using a "BeforeBuild" step.

It now seems to build OK.

View more solutions

Comments

[g.foley]

I check this and it wasn't the case, Thank you anyway tho.

[VoodooChild]

Great. just one question: How did you find out that it had no detected dependencies? which option is this in? please elaborate. thanks

[g.foley]

In my deployment project there is a detected dependencies folder. The only thing it was detecting in there was the .net framework. You can right click on this folder and click "Refresh dependencies", but even this wasn't working for me. When i re-added the primary output the dependencies were detected. It was very odd, and was caused sometime during the conversion between vs2008 and vs2010. I'd say its a bug but for the fact that all my other deployment projects converted perfectly. At the end of the day i have no idea what has happened.

[Paul Hiles]

I had the same problem with a newly created solution in vs.net 2010, so it is not an upgrade issue. As you said, removing the primary output and readding seems to fix the issue.

[Brian Chavez]

could someone please clarify what "remove the primary output" means?

[snaits]

Bug is still there in VS2012. It really should be fixed, took me a while to find this solution.

[JustAMartin]

Today I discovered that this CopyLocal trick does not affect the references above the current project. For example, I have a project Entities which references some.dll in GAC. If I force CopyLocal=true for some.dll as described above, everything seems fine - some.dll gets copied to the bin folder of Entities. But if I reference the Entities project in some project Services and expect to get some.dll copied to the Services\bin, it won't happen - Services project ignores CopyLocal=true of the Entities project and still grabs the some.dll from the GAC. Using VS2012.

[longda]

Although this fixes the project file, this setting is still not respected by MSBuild.exe from the command line so any sort of automated build scripts will not be building the code correctly (e.g. the referenced project reference dll will not be in the bin directory)

[Didier A.]

@longda I am having the same problem. I have project references that should be copied over, but even with Copy Local to true and Private to true, msbuild in command line will not copy them over.

[Matthew]

I also get this issue. Complete waste of time, Microsoft should fix this.

[empty]

I'm running into this is VS2013 when I configure nuGet to supply missing packages. The only way I've found to succesfully work around this is to add references to the missing assemblies to my starting project. Yecch.

[Paul Kohler]

There are probably many Connect bugs on this type of issue - I added one as best I could explain! connect.microsoft.com/VisualStudio/feedback/details/1113297 Feel free to vote on it!! Post here if you find a better connect issue to use.....

[philreed]

I just had the same issue in VS2015. FYI, the XML references mentioned in this answer are stored in the project file, not the solution file.

[aeroson]

he likely means this: image.prntscr.com/image/1769f5e6958c4f89a865ed35d5e92224.png

[FishySwede]

Adding VS2017 to the list

[Yesh]

VS2017 still has this bug :(