System.Drawing.Common.dll is not added to Net Core build output

[Persimus]

Steps to reproduce

Create an application for .Net Core add System.Drawing.Common Nuget or Direct dll reference, and build. You will see that the dll is not in the output directory.

This issue causes runtime errors in Linux containers if you run Build and Publish processes on Windows machine or TFS server and then try to run them on Linux container. When processes that needs dll to run is called exception is thrown: "System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing.Common'", otherwise no build or deploy issues were observed.

Issue observed after updating From: Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core To: Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core

Project file

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Drawing.Common" Version="4.7.0" />
  </ItemGroup>

</Project>

Expected behavior

System.Drawing.Common.dll is in output directory

Actual behavior

System.Drawing.Common.dll is not added

OS info: Windows 10, TFS server

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc): Build Engine version 16.5.0+d4cbfca49 for .NET Core

[KirillOsenkov]

Hi @Persimus have you tried using https://msbuildlog.com to obtain a .binlog from your scenario and investigate it? You can search for did not copy System.Drawing.Common.dll in the log viewer.

Here's a more detailed article about how to investigate issues like these: https://github.com/microsoft/msbuild/blob/master/documentation/wiki/ResolveAssemblyReference.md

[Persimus]

Thank you @KirillOsenkov for sharing the tool. It seems that on 16.5 the System.Drawing.Common and some other libraries in my project are set to CopyLocal = false while I assume on older version 16.4 it was set to CopyLocal = true

[KirillOsenkov]

Hmm, this is interesting. I am able to reproduce, and indeed the files are not copied to output at all.

Not sure how, if ever, it used to work before.

I do see that ResolvePackageAssets adds the .dll to the RuntimeCopyLocalItems:

Aha, but I do see that if you set the CopyLocalLockFileAssemblies to true they will get copied:

msbuild /r /bl 1.csproj /p:CopyLocalLockFileAssemblies=true

Or, in the .csproj file:

<PropertyGroup>
  <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>

Can you try that and see if it works? Not sure if it's a bug or by-design, and whether it's documented anywhere.

[KirillOsenkov]

I've filed an issue here to clarify and document this behavior so it's not so confusing: https://github.com/microsoft/msbuild/issues/5321

Meanwhile, @Persimus have you tried invoking dotnet publish or msbuild /r /bl /t:Publish? This should produce properly laid out output and copy all the necessary things.

[Persimus]

I think I need to elaborate as my issue is a bit more complex. I am using EPPlus package in one of my libraries to generate Excel file, it has a System.Drawing.Common as one of their dependencies. So my dependency tree look like this:

• WebService
  • ExcelLibrary
  • EPPlus
    • System.Drawing.Common

At first (a year ago) I had some issues with System.Drawing.Common library not appearing in the publish (as I needed to be in Linux container) so I added to my ExcelLibrary, like this:

• WebService
  • ExcelLibrary
  • System.Drawing.Common
  • EPPlus
    • System.Drawing.Common

Everything worked fine, build on my machine and TFS build server generated dll and I pushed TFS published content directly into my pod as dlls in my deploy pipeline.

System worked as intended until MSbuild 16.5 update, I am sure about cause of the problem because I have two almost identical builds an hour apart of which first worked fine and the second had missing dlls in its artifacts, only difference Build Engine version.

So now what I have tried, and what doesn't work:

• Adding <RestoreProjectStyle>PackageReference</RestoreProjectStyle> doesn't work.
• Adding <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to ExcelLibrary works as it creates dll in libraries build directory, but doesn't move the dlls to the WebService, adding <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to WebService doesn't change anything either, even though packages.lock.json are the same: "System.Drawing.Common": { "type": "Transitive", "resolved": "4.7.0", "contentHash": "v+XbyYHaZjDfn0ENmJEV1VYLgGgCTx1gnfOBcppowbpOAriglYgGCvFCPr2EEZyBvXlpxbEsTwkOlInl107ahA==", "dependencies": { "Microsoft.NETCore.Platforms": "3.1.0", "Microsoft.Win32.SystemEvents": "4.7.0" } }
• Adding System.Drawing.Common Nuget to WebService doesn't work, also removing one from ExcelLibrary doesn't work.
• Adding direct reference to System.Drawing.Common.dll for either WebService or ExcelLibrary doesn't work.
• dotnet build or dotnet publish, and Visual Studio Build doesn't work
• Weird combinations of above also don't work.

Any additional possible solutions are welcome.

[KirillOsenkov]

@cdmihai

[rainersigwald]

This issue was moved to dotnet/sdk#11489