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

Question

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!)

Solution 1

I'm not sure why it is different when building between Visual Studio and MsBuild, but here is what I have found when I've encountered this problem in MsBuild and Visual Studio.

Explanation

For a sample scenario let's say we have project X, assembly A, and assembly B. Assembly A references assembly B, so project X includes a reference to both A and B. Also, project X includes code that references assembly A (e.g. A.SomeFunction()). Now, you create a new project Y which references project X.

So the dependency chain looks like this: Y => X => A => B

Visual Studio / MSBuild tries to be smart and only bring references over into project Y that it detects as being required by project X; it does this to avoid reference pollution in project Y. The problem is, since project X doesn't actually contain any code that explicitly uses assembly B (e.g. B.SomeFunction()), VS/MSBuild doesn't detect that B is required by X, and thus doesn't copy it over into project Y's bin directory; it only copies the X and A assemblies.

Solution

You have two options to solve this problem, both of which will result in assembly B being copied to project Y's bin directory:

1. Add a reference to assembly B in project Y.
2. Add dummy code to a file in project X that uses assembly B.

Personally I prefer option 2 for a couple reasons.

1. If you add another project in the future that references project X, you won't have to remember to also include a reference to assembly B (like you would have to do with option 1).
2. You can have explicit comments saying why the dummy code needs to be there and not to remove it. So if somebody does delete the code by accident (say with a refactor tool that looks for unused code), you can easily see from source control that the code is required and to restore it. If you use option 1 and somebody uses a refactor tool to clean up unused references, you don't have any comments; you will just see that a reference was removed from the .csproj file.

Here is a sample of the "dummy code" that I typically add when I encounter this situation.

    // DO NOT DELETE THIS CODE UNLESS WE NO LONGER REQUIRE ASSEMBLY A!!!
    private void DummyFunctionToMakeSureReferencesGetCopiedProperly_DO_NOT_DELETE_THIS_CODE()
    {
        // Assembly A is used by this file, and that assembly depends on assembly B,
        // but this project does not have any code that explicitly references assembly B. Therefore, when another project references
        // this project, this project's assembly and the assembly A get copied to the project's bin directory, but not
        // assembly B. So in order to get the required assembly B copied over, we add some dummy code here (that never
        // gets called) that references assembly B; this will flag VS/MSBuild to copy the required assembly B over as well.
        var dummyType = typeof(B.SomeClass);
        Console.WriteLine(dummyType.FullName);
    }

Solution 2

I just deal with it like this. Go to the properties of your reference and do this:

Set "Copy local = false"
Save
Set "Copy local = true"
Save

and that's it.

Visual Studio 2010 doesn't initially put: <private>True</private> in the reference tag and setting "copy local" to false causes it to create the tag. Afterwards it will set it to true and false accordingly.

Solution 3

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.

Solution 4

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!)

Solution 5

I had the same problem.

Check if the framework version of your project is the same of the framework version of the dll that you put on reference.

In my case, my client was compiled using "Framework 4 Client" and the DLL was in "Framework 4".

View more solutions

Comments

[David Faivre]

I'd love to get a clearer answer for why this happens.

[Anuroopa Shenoy]

Take a look at the answer provided here

[Kiquenet]

any final solution with full source code sample working about it ?

[Jeff Widmer]

See the answer stackoverflow.com/a/21055664/21579 below by @deadlydog. Excellent explanation and resolved the issue for me... the most voted answer below is not correct for VS2012.

[Zack]

vote this up connect.microsoft.com/VisualStudio/feedback/details/652785/…

[Worthy7]

FWIW, I think this prop was removed by nuget somewhere along the way

[Kit Roed]

+1 for your copy to Output Directory comment, if Elmah isn't being used in code, makes sense to copy as content.

[Alex Burtsev]

Indeed it ignores assemblies that are not used, BUT one major thing to note, as of VS 2010 using assembly in XAML resource dictionaries is not considered as using assmebly by VS, so it will not copy it.

[Alex Burtsev]

connect.microsoft.com/VisualStudio/feedback/details/693740/…

[Rebecca]

This was a godsend. Thank you for this!

[Martin]

This worked for me as well. The DLLs were not being copied when doing a TFS build, and this fixed it.

[Michael Teper]

Didn't work for me with MSBuild 4 / VS2012. That is, I was able to update references to say <Private>true</Private> but it seemed to have no effect on MSBuild. In the end, I just added NuGet references to downlevel projects.

[felickz]

@MichaelTeper i had to do this + change Copy Local to False then to True to get <Private>True setting in csproj... after this everything copied as expected

[nickspoon]

Damn - this is the only solution I had come to too - hoped there might be a better way to do it!

[MPritchard]

See andrew's reponse below for a less hacky solution (no offence!)

[Akira Yamamoto]

Didn't work for me. It still doesn't copy System.Net.Http.Formatting to the bin folder.

[longda]

@felickz - Any chance you could post your answer? I'm having the same issue and I'd gladly upvote you if it works!

[felickz]

@Iongda just make sure your ref in csproj looks has <Private>True</Private>. This was my issue. <Reference Include="Microsoft.ApplicationServer.Caching.Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\..\..\packages\ServerAppFabric.Client.1.1.2106\‌​lib\Microsoft.Applic‌​ationServer.Caching.‌​Client.dll</HintPath‌​> <Private>True</Private> </Reference>

[Andez]

In VS2013 UI Project References, you can just switch between Copy Local True to False to True for all references then save. It will then copy the binaries to the bin folder. Weird this issue just started today for me.

[FarFigNewton]

This is the equivalent to Have you tried turning it off and on again?, and it worked!

[user1164178]

What isn't being discussed here is that there is a difference between the copying of build products in /bin of a web project and the routine copying to the target output directory (e.g. /bin/x86/Debug). The former is done by the referenced project when it builds and the latter is done by the dependent web project. Examining Microsoft.Common.targets helps understand this. Copies to the web /bin do not depend on copy local behaviour at all - copy local impacts on the copy to the output target dir which is not part of the structure referenced by Cassini running via Debug.

[toebens]

as written above i've set <Private>true</Private> in project file but this did not help (at least for sure way back then with VS 2008). see deadlydog's answer for an explanation and a possible workaround and/or my own answer. However i'm still confused why that worked in VS but not with msbuild. Anyway i had this problem long time ago and hope this problem was fixed with newer VS versions by Microsoft.

[toebens]

can you explain why it had worked with VS WITHOUT adding that "dummy code" but not with msbuild?

[Arithmomaniac]

Even less invasive than invoking a function, you can assign the type of a class contained inside the assembly to a dummy variable. Type dummyType = typeof(AssemblyA.AnyClass);

[deadlydog]

@Arithmomaniac Thanks! I've updated the post with your modification :)

[Greg Z.]

Solution #1 didn't work for me. Solution #2 also would not work for me because the assembly in question (Oracle.ManagedDataAccess.EntityFramework.dll) does not expose ANY public types! Any other ideas?

[JasonG]

Solution #2 as shown above will work unless you have the 'Optimize Code' setting checked in Visual Studio. In that case, it will still exclude the dll. I added one more line to override its "optimization". Console.WriteLine(dummyType.FullName);

[flip]

Looks like VS2015 still behaves the same: setting 'Copy Local' to 'False' then back to 'True' on referenced .dll's, works.

[deadlydog]

Thanks @JasonG I've updated the solution with the extra line you mentioned

[bigbearzhu]

What if all classes in the assembly B are internal? I had this issue with Microsoft.SqlServer.SqlClrProvider.dll. But all the classes in that dll are internal.

[deadlydog]

@bigbearzhu hmmm, that's a tough one. I'm not sure if you could maybe instantiate one of the classes via reflection? Other than that, I guess you might just have to go with option #1.

[kay]

This was exactly my issue and the solution that worked. Spent too long trying to figure this out. Thanks Scott & @Alex Burstev

[Suncat2000]

This answer makes sense once I got past the confusing bit of the sample dependency illustration having the arrows going in the wrong direction.

[Suncat2000]

After many hours of searching and trying many of the other solutions, this one worked for me.

[Xharlie]

Solution 2 did not work for me in Visual Studio 2017. I first thought it was because, in my assembly X, I was only using an enum from B and I assumed the enum was being inlined. I added code to directly use a type from B and that didn't help. It has also always been the case the my X uses types in A that subclass types in B so I cannot fathom how the compiler thinks that B is not required by X and can be ignored. This is bonkers.

[Shahzad]

Works for me with VS. But does not work with MSBuild

[Andy Hoyle]

I had the same issue building whole solution using /t:Build from TeamCity in one step then in the next /t:Package on WebAPI project. Any dlls referenced by any project references were not included. This was fixed using the above - /T:Rebuild;Package on the WebAPI then included those dlls.

[Ji_in_coding]

Nice solution! For those that can NOT get this method to work; Edit project file in text editor, find the reference to dll, remove any <Private>True/False</Private> from that dll dependency, save. Then go back to VS, right click dll reference and view properties.One should be able to set the copy local property for this dependency.

[Royi Mindel]

Works in VS2017 :)

[Sören Kuklau]

Good grief, this was driving me crazy. Yes, I was using FontAwesome.WPF, and only from within the XAML (for obvious reasons). Adding a dummy method helped. Thanks! And yes, VS 2017 15.6 is still affected, so I filed a bug: github.com/dotnet/roslyn/issues/25349

[rahulaga-msft]

@deadlydog : The problem is, since project X doesn't actually contain any code that explicitly uses assembly B i did not understand this point. Its being quite old post, things changed ? Shouldn't msbuild should refer to assembly A manifest to check for dependent assemblies ? I do refer nuget packages where this is common scenario where my project will directly calling api on main assembly and main assembly internally must be using dependent assemblies. I never have to write dummy code for dependent assemblies.

[Lukos]

This is better for a Unit Test project where I need the dll. I don't want to add a dll that the main project doesn't need just to make the tests run!

[Khoait]

I also had to remove the reference and save; and add it back and save prior to your steps. Thanks!

[jpaugh]

For those looking at this now, toebens' answer on MSDN is essentially the same as deadlydog's answer, provided some years later.

[Giles Roberts]

This is a duplicate of the top answer.

[AaronLS]

In VS 2019 this bug still exists, and the workaround still works. Make sure to do a Save All between each action, so your save effects the project.

[Mark]

Didn't work for me in VS 2019. I followed the steps and confirmed that <Private>True</Private> was set, but still the dll wasn't copied. The accepted answer did work for me.

[StayOnTarget]

It would be interesting to diff the csproj files before & after to see what changed

[Gowrav]

@rahulaga_dev you are correct. I dont think deadlydog answer is quite right. I recreated the scenario with Y => X => A => B and all I had to do was run the command "msbuild -t:clean,rebuild,pack"