UseCommonOutputDirectory=true breaks CopyLocalLockFileAssemblies flag

[human33]

Describe the bug

NuGet dependencies aren't getting copied if I set UseCommonOutputDirectory=true and CopyLocalLockFileAssemblies=true in my .csproj file.

To Reproduce

1. Clone https://github.com/human33/dotnent-sdk-ref-copy-issue
2. Build and run

What happens: It crashes with Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'CJE, Version=3.3.10.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
because no dll was copied to output directory.

What should happen: CJE.dll should be copied to output dir during building process and console should print Hello World!CJE.Event.

Further technical details

• Include the output of dotnet --info

.NET SDK (reflecting any global.json):
Version: 6.0.101
Commit: ef49f62

Runtime Environment:
OS Name: ubuntu
OS Version: 21.10
OS Platform: Linux
RID: ubuntu.21.10-x64
Base Path: /usr/share/dotnet/sdk/6.0.101/

Host (useful for support):
Version: 6.0.1
Commit: 3a25a7f1cc

.NET SDKs installed:
5.0.404 [/usr/share/dotnet/sdk]
6.0.101 [/usr/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

JetBrains Rider 2021.3.2, but works the same if I use dotnent run in project dir

---

I'm trying to use UseCommonOutputDirectory because this comment suggested this and I need to build my projects to one common directory.

[human33]

Also, if I set verbosity level to "Detailed", I see messages like:

This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true".

If it's not too complicated and somebody can help me by telling me where to look to fix the issue, I could try to fix it in my spare time.

[KalleOlaviNiemitalo]

The message about "CopyLocal" and "Private" comes even if you don't set UseCommonOutputDirectory.

The DLL in the package would normally be copied by the _CopyFilesMarkedCopyLocal target, but if '$(UseCommonOutputDirectory)' == 'true', then that target does not copy anything. So the fix might be that you make the _CopyFilesMarkedCopyLocal target detect if some of the ReferenceCopyLocalPaths items came from NuGet packages, and copy them regardless of UseCommonOutputDirectory. On the other hand, if the items came from framework NuGet packages like Microsoft.WindowsDesktop.App.Ref, then I guess those still should not be copied. It seems pretty complicated.

[human33]

@KalleOlaviNiemitalo thanks for the explanation.

[jozefsivek]

This is clear regression in dotnet 6. Projects with <TargetFramework>net5.0</TargetFramework> do work, while <TargetFramework>net6.0</TargetFramework> will result in aforementioned error, when using <UseCommonOutputDirectory>True</UseCommonOutputDirectory>.

Is there any update on when to expect solution? Building the solution to one directory, in order to save resources, should not be something impossible.

Note that for net6.0 projects without <UseCommonOutputDirectory>True</UseCommonOutputDirectory> the libraries like Microsoft.Win32.Registry.dll are copied too, which was not the case for net5.0 projects, whatever the reason is.

[justinswork]

Thanks for documenting this @jozefsivek I am seeing this regression as well

[bkoelman]

I'm trying to upgrade a working .NET 5 project that uses UseCommonOutputDirectory to .NET 6. After updating the TFM, xUnit tests no longer work.

Starting test discovery for requested test run
========== Starting test discovery ==========
Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Testhost process exited with error: Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.TestPlatform.CoreUtilities, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'Microsoft.TestPlatform.CoreUtilities, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main(String[] args)
. Please check the diagnostic logs for more information.
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.ThrowOnTestHostExited(Boolean testHostExited)
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings)
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyDiscoveryManager.DiscoverTests(DiscoveryCriteria discoveryCriteria, ITestDiscoveryEventsHandler2 eventHandler)
========== Test discovery aborted: 0 Tests found in 1.4 sec ==========
========== Starting test run ==========
========== Test run finished: 0 Tests (0 Passed, 0 Failed, 0 Skipped) run in < 1 ms ==========

[yzbai]

@bkoelman Maybe your Test Project use UseCommonOutputDirectory=true ?
Test Projects should not use this.
Refer to this: dotnet/roslyn#8975 (comment)

[bkoelman]

@yzbai Thanks, that helps. I had UseCommonOutputDirectory in Directory.Build.props, which I now made conditional for non-test projects:

<PropertyGroup Condition="!$(MSBuildProjectName.EndsWith('Test'))">

Unfortunately, that brings me back to the original issue that DLLs from NuGet dependencies aren't being copied.

Adding <GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile> helps for local development, but pointing to paths into my local user profile directory still prevents me from zipping up the output for someone else.

[lilith]

Related: #27320 - UseCommonOutputDirectory breaks dotnet test

[Gav-Brown]

If it helps, I posted a possible solution here which allows you to not set UseCommonOutputDirectory but just the OutputDir and then projects, dlls, and NuGet dlls all get copied to a single "bin" folder without missing deps.json files etc.

[ChristoWolf]

I am observing the same issue in .NET 6 projects.
UseCommonOutputDirectory=true works, but even with CopyLocalLockFileAssemblies=true no NuGet dependencies are copied.

[jspanoeddson]

Any word on a fix for this? Pretty annoying. Have to remember to copy new stuff to the output directory.

[marcpopMSFT]

Old issue triage: @rainersigwald is this just a known gap in UseCommonOutputDirectory? Any suggestions?

[marcpopMSFT]

FWIW, it might be worth us documenting all the recommended ways of managing outputs for projects. We could also explore the concept of a metaproject that pulls together the outputs of all the dependencies that gives the result of UseCommonOutputDirectory but works better.

[lilith]

I agree, this is area is a deep source of misery, especially when you combine multiple framework targets, native dlls, xplat, package publishing, and unit testing. Having some approach that actually works would be incredible.

…

On Tue, May 20, 2025, 2:51 PM Marc Paine ***@***.***> wrote: *marcpopMSFT* left a comment (dotnet/sdk#23342) <#23342 (comment)> FWIW, it might be worth us documenting all the recommended ways of managing outputs for projects. We could also explore the concept of a metaproject that pulls together the outputs of all the dependencies that gives the result of UseCommonOutputDirectory but works better. — Reply to this email directly, view it on GitHub <#23342 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LHYROYOKQRIEQGGPQC327OIUNAVCNFSM6AAAAABRU3ZXLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOJVHAYDCMJZGY> . You are receiving this because you commented.Message ID: ***@***.***>

[dsplaisted]

Per discussion on #23366, for some people setting GenerateRuntimeConfigDevFile to true may resolve this. That setting will write a runtimeconfig.dev.json which will direct the runtime to look for libraries in the NuGet package folders that were used in the build.