#SharePointProblems | Koskila.net

Solutions are worthless unless shared! Antti K. Koskela's Personal Professional Blog

How to copy dependent assemblies to the bin folder on build?

koskila
Reading Time 2 min
Word Count 340 words
Comments 11 comments
Rating 5 (3 votes)
View

This is something that comes up pretty often - when you're building an application, or maybe a library you're sharing as a NuGet package to your friends: You'll need to share a dependency or two with your particular package, and you don't want your end users having to reference those libraries, too.

Sounds easy, right? But alas, it's not as simple as one would like :)

(Well, unless you're happy running dotnet publish every time - that should work, but I want to have these files available right after dotnet build instead)

Problem

Sounds easy, right? There's a problem, though - you can't just set "Copy Local" to "true" anymore. That's simply not available for your dependencies.

And forget all of that nonsense inside your PackageReferences - probably not going to help either.

At least I was getting a bit frustrated. Couldn't find a way to include the DLLs without building some super questionable build conditions and/or scripts. Or, well, running dotnet publish all the time.

However, there's another solution available!

Solution

The solution includes modifying your .csproj file (because of course it does!) - let's see how:

Time needed: 5 minutes.

How to copy referenced assemblies to the bin folder on build?

  1. Open your project file

    Simple enough, just select "Edit Project File" by clicking your project using the right mouse button in the Solution Explorer.

    "Edit Project File" in Visual Studio Solution Explorer

  2. Add CopyLocalLockFileAssemblies to your .csproj file

    Okay - so you need to add this inside your ...</PropertyGroup:

    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

    This will copy all of the NuGet dependencies to your output directory.

    The documentation says this:
    If you set this property to true, any NuGet package dependencies are copied to the output directory. That means you can use the output of dotnet build to run your plugin on any machine.

  3. Reload project and rebuild

    After reloading and rebuilding you should be good!


And that's it!

How did it go for you? Let me know in the comments section below!

References

Comments

Interactive comments not implemented yet. Showing legacy comments migrated from WordPress.
Brian
2022-04-25 23:00:57)
This works, it works too well. It copies all referenced files to the build directory. I'm working as a plugin and the host application already has some of those dlls in it's path and when I add my own copies, I now get an error for duplicate assemblies: Found duplicate assembly Amazon.Extensions.Configuration.SystemsManager at C:\Server\Amazon.Extensions.Configuration.SystemsManager.dll, C:\Server\plugins\CBH.Facade\Debug\netstandard2.1\Amazon.Extensions.Configuration.SystemsManager.dll Ideas on how to copy only select nuget packages to the build directory?
2022-06-11 21:46:23
Hi Brian, True, that becomes a problem if you have multiple versions of the same dependency. I didn't think it should be a problem if the versions match..? But if you run into this, I reckon you have at least 2 options: 1) just add said dependency to the project you're building directly (ugly) 2) create an msbuild script to run xcopy after your build has finished to copy the dlls (finicky) If you run into any other solutions, please do let me know! 😅
Arun
2022-06-14 06:34:35)
But when I do have msbuild with the option "UseCommonOutputDirectory="true" , then this trick wouldn't work :( And if I even do not use the above option, I seem to get the dependencies in the output folder without having to do anything. Any thoughts ?
Antti K. Koskela
2023-03-10 22:31:44
Hi Arun, Ah, an interesting question - I found other people complaining the same starting with .NET 6, calling it a recent regression. A couple of possible workarounds were linked in this discussion: https://github.com/dotnet/sdk/issues/23342
javid
2022-06-17 10:10:05)
thanks
2022-06-28 19:05:02
My pleasure, mate!
Ada
2022-09-28 07:40:12)
Thank you - I was having the same frustrations and rant with this whole process. It's dumb that I had to scroll down a fair bit to find your post, as the top post on this issue is a stackoverflow answer with a lazy "edit your propertygroup to this" with zero explanation of what that is or where it can be found *sigh*... Thanks for actually showing where it can be found clearly.
Antti K. Koskela
2022-11-02 15:55:22
Thanks for your comment, Ada! Well, ain't much we can do about Google's algorithm, but I'm happy you found my article nonetheless! :)
Slobodan
2022-12-22 00:30:55)
Thanks! That works nice for NuGet packages, but how do you force project reference DLLs to be copied over?
Slobodan
2022-12-22 04:46:30)
Ok, adding these lines into csproj file solves the project references:
	<ItemDefinitionGroup>
		<ProjectReference>
			<Private>True</Private>
		</ProjectReference>
	</ItemDefinitionGroup>
Antti K. Koskela
2023-03-03 18:54:27
Hi Slobodan, Sorry for coming in a bit late, but many thanks for your contribution!
Whitewater Magpie Ltd.
© 2025
Static Site Generation timestamp: 2025-08-26T05:15:47Z