UseCommonOutputDirectory=true breaks CopyLocalLockFileAssemblies flag
See original GitHub issueDescribe the bug
NuGet dependencies aren’t getting copied if I set UseCommonOutputDirectory=true and CopyLocalLockFileAssemblies=true in my .csproj file.
To Reproduce
- Clone https://github.com/human33/dotnent-sdk-ref-copy-issue
- 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: ef49f6213a
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.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:11 (2 by maintainers)
Top GitHub Comments
Thanks for documenting this @jozefsivek I am seeing this regression as well
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 likeMicrosoft.Win32.Registry.dll
are copied too, which was not the case for net5.0 projects, whatever the reason is.