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

E

20

300

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

MyBaseProject <- this class library references a third-party DLL file (elmah.dll)
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!)

Elbert answered 15/7, 2009 at 15:46 Comment(6)

I'd love to get a clearer answer for why this happens. – Site 27/4, 2012 at 17:18

Take a look at the answer provided here – Beesley 22/8, 2012 at 15:31

any final solution with full source code sample working about it ? – Lymphocytosis 13/5, 2013 at 14:24

See the answer https://mcmap.net/q/99761/-msbuild-doesn-39-t-copy-references-dll-files-if-using-project-dependencies-in-solution below by @deadlydog. Excellent explanation and resolved the issue for me... the most voted answer below is not correct for VS2012. – Velar 8/5, 2014 at 14:29

vote this up connect.microsoft.com/VisualStudio/feedback/details/652785/… – Scapegoat 8/6, 2017 at 20:41

FWIW, I think this prop was removed by nuget somewhere along the way – Gazette 15/11, 2017 at 5:28

B

173

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:

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

Personally I prefer option 2 for a couple reasons.

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).
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);
    }

Biisk answered 10/1, 2014 at 22:30 Comment(14)

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. – Sarre 18/7, 2014 at 4:55

can you explain why it had worked with VS WITHOUT adding that "dummy code" but not with msbuild? – Elbert 25/2, 2015 at 20:54

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); – Alvis 16/3, 2015 at 14:50

@Alvis Thanks! I've updated the post with your modification :) – Biisk 16/3, 2015 at 16:12

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? – Lampoon 26/6, 2015 at 18:50

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); – Fifine 24/7, 2015 at 20:22

Thanks @Fifine I've updated the solution with the extra line you mentioned – Biisk 19/1, 2016 at 16:37

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. – Berky 22/1, 2016 at 6:10

@Berky 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. – Biisk 22/1, 2016 at 21:28

This answer makes sense once I got past the confusing bit of the sample dependency illustration having the arrows going in the wrong direction. – Telium 3/3, 2017 at 13:13

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. – Mirtamirth 25/4, 2017 at 12:18

@Biisk : 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. – Haw 16/3, 2018 at 13:16

@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" – Farinaceous 31/12, 2021 at 6:11

@Haw this answer is about project references. Things work differently with package references. – Krak 5/4, 2023 at 14:34

D

173

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.

Direct answered 21/10, 2011 at 23:54 Comment(16)

This worked for me as well. The DLLs were not being copied when doing a TFS build, and this fixed it. – Pharmacognosy 6/3, 2012 at 15:44

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. – Pregnancy 18/1, 2013 at 21:48

@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 – Fluoroscopy 14/5, 2013 at 16:26

Didn't work for me. It still doesn't copy System.Net.Http.Formatting to the bin folder. – Risteau 8/11, 2013 at 16:25

@Fluoroscopy - Any chance you could post your answer? I'm having the same issue and I'd gladly upvote you if it works! – Sapanwood 10/2, 2014 at 23:16

@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.ApplicationServer.Caching.Client.dll</HintPath>       <Private>True</Private>     </Reference>

– Fluoroscopy 11/2, 2014 at 13:34

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. – Eightieth 26/3, 2014 at 11:55

This is the equivalent to Have you tried turning it off and on again?, and it worked! – Expediency 18/6, 2014 at 20:52

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. – Elbert 25/2, 2015 at 20:51

Looks like VS2015 still behaves the same: setting 'Copy Local' to 'False' then back to 'True' on referenced .dll's, works. – Eulau 23/8, 2015 at 4:59

Works for me with VS. But does not work with MSBuild – Quiz 21/7, 2017 at 15:14

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. – Celindaceline 8/11, 2017 at 15:18

Works in VS2017 :) – Masaryk 22/1, 2018 at 7:54

I also had to remove the reference and save; and add it back and save prior to your steps. Thanks! – Tagmemic 6/11, 2018 at 12:25

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. – Plug 11/3, 2020 at 21:1

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. – Merriemerrielle 30/12, 2020 at 3:32

B

173