dotnet publish should not include static libraries

[0xced]

On macOS (and maybe also on Linux, I have not tried) five static libraries end up in the publish directory when publishing an executable with dotnet publish -c Release -r osx-x64 (reproducible with a hello world console app):

• libSystem.IO.Compression.Native.a
• libSystem.Native.a
• libSystem.Net.Security.Native.a
• libSystem.Security.Cryptography.Native.Apple.a
• libSystem.Security.Cryptography.Native.OpenSsl.a

Those are not required at runtime (only dynamic libraries are used) and should not be included in the publish directory.

As a workaround I have added this in my csproj file:

<Target Name="RemoveStaticLibraries" AfterTargets="ResolveRuntimePackAssets">
  <ItemGroup>
    <RuntimePackAsset Remove="@(RuntimePackAsset)" Condition="'%(Extension)' == '.a'" />
    <ReferenceCopyLocalPaths Remove="@(ReferenceCopyLocalPaths)" Condition="'%(Extension)' == '.a'" />
  </ItemGroup>
</Target>

Ideally this workaround should not be needed and the SDK should be responsible for not publishing the static library files.

Technical details (gathered by analyzing the binary build log with MSBuild Log Viewer, reading and grepping source code in dotnet repositories):

• The static library files are copied into the publish directory because they are part of the output of the ResolveRuntimePackAssets MSBuild task.
• The ResolveRuntimePackAssets MSBuild task reads a RuntimeList.xml file, apparently from the Microsoft.NETCore.App.Runtime.osx-x64 NuGet package in the data directory.
• The RuntimeList.xml file seems to be created by the GenerateRuntimeListFile target (dotnet/runtime repository).
• The GenerateRuntimeListFile target calls the CreateFrameworkListFile MSBuild task (dotnet/arcade repository) to create the RuntimeList.xml file.

I think that what should be fixed is the RuntimePackNativeFile item. It includes everything $(MicrosoftNetCoreAppRuntimePackNativeDir)*.* but should probably exclude .a files. I'll let someone at Microsoft more exerienced than me confirm my intuition though.

[sfoslund]

I assume this repros with all versions of the SDK, correct? My instinct is that we likely don't want to change this behavior, but do you have any thoughts @wli3?

[wli3]

@jeffschwMSFT could you help us route to the right person to answer the question? If these files are not runtime asset, they should only be include in targeting pack instead of runtime pack.

[jeffschwMSFT]

We removed these in .NET 5 RC2. What version is this for?

cc @vitek-karas

[0xced]

We removed these in .NET 5 RC2.

Oh that's great. Could you please show me how you did it? I.e. point me at the exact commit that removed them? I was probably looking at the wrong branch during my investigations. Or I did not properly understand how everything is packaged together.

What version is this for?

Sorry I forgot to mention. I have observed that static libraries end up in the publish directory with both 3.1.402 and 5.0.100-rc.1.20452.10 SDKs.

[vitek-karas]

We fixed this in master branch dotnet/runtime#41966, but the port to RC2 was rejected by triage: dotnet/runtime#41986.
So AFAIK we will ship 5.0 still with these files included in self-contained apps.

[0xced]

Thanks for the clarification, Vitek. Don't you think that the .a files should not even end up in the RuntimeList.xml file as I described in my original post, though?

[jeffschwMSFT]

Oh man, I thought that we took that change. You are right we could not safely remove them so late.

[vitek-karas]

@0xced sorry I don't remember the details anymore. I agree they should not be mentioned anywhere in the runtime pack, but I don't know if my "fix" actually fixes the runtime list.

[akoeplinger]

I can confirm that the files no longer show up in RuntimeList.xml after the fix.