dotnet / linker

388 stars 126 forks source link

NETSDK1144: Optimizing assemblies for size failed .NET 7 #3119

Open Clive321A opened 1 year ago

Clive321A commented 1 year ago

I have upgraded a Blazor client app from .net 6 to .net 7 and I'm getting this while building a container image

Error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false.

I am using this in my DockerFile FROM mcr.microsoft.com/dotnet/sdk:7.0 AS base

Adding PublishTrimmed false PublishTrimmed

to the blazor client project file does "fix" the issue, but im not really sure what the actual issue is? https://learn.microsoft.com/en-us/dotnet/core/tools/sdk-errors/ Refers to the error, with no information.

marek-safar commented 1 year ago

Could you share any details (e.g. stack trace) of what failed?

Clive321A commented 1 year ago

Hi, I cant see any stack trace I just get that error when doing a docker-compose --build this seems to be as much as I can see the --verbose option doesnt work with a --build

14 102.2 /usr/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.ILLink.Tasks/build/Microsoft.NET.ILLink.targets(133,5): error MSB6006: "dotnet" exited with code 137. [/src/Client/iUWWorkbench.Client.csproj]

14 102.2 /usr/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.ILLink.Tasks/build/Microsoft.NET.ILLink.targets(86,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false. [/src/Client/iUWWorkbench.Client.csproj]

-

sbomer commented 1 year ago

137 is usually the exit status when a process is terminated by SIGKILL, for example when it runs out of memory. From a quick search I am seeing many issues about other tools failing with status 137 when run in a container, so I suspect there's not enough memory available to your container.

If that's correct, it would be nice for this to show up as an OutOfMemoryException instead, but I don't know enough about OOM hardening in .NET. It would be interesting to experiment with a repro if you are able to share anything.

Clive321A commented 1 year ago

Excellent, that's exactly what it was thanks, I bumped the memory in docker and it builds now with PublishTrimmed on. Unfortunately I dont have a demo repo, ill see if I can create one if I get some time this week. thanks again

marek-safar commented 1 year ago

@CliveBennett out of curiosity, what was the limit before?

Clive321A commented 1 year ago

I went from 2GB to 6GB, (I have 4 .net 6 apps and 2 MySQL db's applications running in Docker).

(Just for local development)

jmalczak commented 1 year ago

I have the same issue when building xamarin android app using .net7. It works fine when build using .net6. Issue exists only in Release mode with linker configured to link sdk assemblies only.

    1>/usr/local/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.ILLink.Tasks/build/Microsoft.NET.ILLink.targets(86,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false.
     1>_RunILLink:
         Fatal error in IL Linker
         Unhandled exception. System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
            at System.Collections.Generic.List`1.Enumerator.MoveNextRare()
            at Mono.Linker.Steps.MarkStep.IsMethodNeededByInstantiatedTypeDueToPreservedScope(MethodDefinition method)
            at Mono.Linker.Steps.MarkStep.GetRequiredMethodsForInstantiatedType(TypeDefinition type)+MoveNext()
            at Mono.Linker.Steps.MarkStep.MarkRequirementsForInstantiatedTypes(TypeDefinition type)
            at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method, DependencyInfo& reason, MessageOrigin& origin)
            at Mono.Linker.Steps.MarkStep.ProcessQueue()
            at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue()
            at Mono.Linker.Steps.MarkStep.Process()
            at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
            at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
            at Mono.Linker.Pipeline.Process(LinkContext context)
[Example.zip](https://github.com/dotnet/linker/files/10050059/Example.zip)

            at Mono.Linker.Driver.Run(ILogger customLogger)
            at Mono.Linker.Driver.Main(String[] args)
         Build continuing because "ContinueOnError" on the task "ILLink" is set to "ErrorAndContinue".
     1>Done Building Project "/Users/malczu/RiderProjects/Solution4/AndroidApp1/AndroidApp1.csproj" (_ComputeFilesToPublishForRuntimeIdentifiers target(s)) -- FAILED.
     1>/usr/local/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.ILLink.Tasks/build/Microsoft.NET.ILLink.targets(86,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false.
     1>Done Building Project "/Users/malczu/RiderProjects/Solution4/AndroidApp1/AndroidApp1.csproj" (_ComputeFilesToPublishForRuntimeIdentifiers target(s)) -- FAILED.
     1>Done Building Project "/Users/malczu/RiderProjects/Solution4/AndroidApp1/AndroidApp1.csproj" (build target(s)) -- FAILED.

I have attached 2 solutions, one with .net6 global.json compiles. The one with .net7 global.json fails on the error above.

Example.zip

Interesting observation is that if I add class that inherit from Activity in root namespace:

using Android.Runtime;
using Core;
using MvvmCross.Platforms.Android.Views;

namespace AndroidApp1;

public class T : Activity
{

}

[Application]
public class MainApplication : MvxAndroidApplication<Setup, App>
{
    public MainApplication(IntPtr javaReference, JniHandleOwnership transfer) : base(javaReference,
        transfer)
    {
    }

    public override void OnCreate()
    {
        base.OnCreate();

        //CrossCurrentActivity.Current.Init(this);
    }
}

Build works fine.

marek-safar commented 1 year ago

@jmalczak I think your issue is different, the original issue reported here is about OOM situation. Your issue looks like duplicate of #3112.