Repository navigation
dotnet publish should not include static libraries #13985
Description
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
ResolveRuntimePackAssetsMSBuild task. - The
ResolveRuntimePackAssetsMSBuild task reads aRuntimeList.xmlfile, apparently from the Microsoft.NETCore.App.Runtime.osx-x64 NuGet package in thedatadirectory. - The
RuntimeList.xmlfile seems to be created by theGenerateRuntimeListFiletarget (dotnet/runtime repository). - The
GenerateRuntimeListFiletarget calls theCreateFrameworkListFileMSBuild task (dotnet/arcade repository) to create theRuntimeList.xmlfile.
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.
Activity
sfoslund commentedon Oct 9, 2020
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 commentedon Oct 9, 2020
@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 commentedon Oct 9, 2020
We removed these in .NET 5 RC2. What version is this for?
cc @vitek-karas
0xced commentedon Oct 9, 2020
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.
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 commentedon Oct 9, 2020
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 commentedon Oct 9, 2020
Thanks for the clarification, Vitek. Don't you think that the
.afiles should not even end up in theRuntimeList.xmlfile as I described in my original post, though?jeffschwMSFT commentedon Oct 9, 2020
Oh man, I thought that we took that change. You are right we could not safely remove them so late.
vitek-karas commentedon Oct 9, 2020
@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 commentedon Oct 28, 2020
I can confirm that the files no longer show up in RuntimeList.xml after the fix.