Add PublishAot flag gives package restore error using global.json

[b12kab]

Description

Looking to reduce the .ipa size, this performance improvement notes the setting the PublishAot flag to true should shrink the size.

Our solution has a global.json file which has no pre-release and limiting it to Net SDK 8.203 (8.0.4). Without this flag, the solution builds out release version iOS .ipa as expected; after adding this to the project file in the release section:

true

and reloading the project after the project saves in Visual Studio Mac, an error shows up the package console (or dotnet restore):

_Unable to find a stable package runtime.linux-arm.Microsoft.DotNet.ILCompiler with version (>= 8.0.3)

• Found 3 version(s) in nuget.org [ Nearest version: 9.0.0-preview.1.24080.9 ]
• Found 0 version(s) in /usr/local/share/dotnet/library-packs_

If a release build done via command line, it gives a similar error.

Given that there is an 8.0.4 version out on the nuget packages for Microsoft.DotNet.ILCompiler, I am unsure why this is occurring. Presently the version is set to 8.0.203, but it also is the same error with 8.0.204.

I also tried to add the nuget for 8.0.4 and it gives a the same error on the project reload.

Reproduction Steps

I've a sample project with the flag set (along with other flags) for a release build showing this behavior for generating a iOS .ipa.

Expected behavior

I would expect this to pull down the 8.0.4 nuget and create a release build .ipa successfully.

Actual behavior

Error on restore (or build if done without restore).

Regression?

If I set the version to 8.0.100 in the global.json, visual studio mac gives this error on the project reload with package restore:

Unable to find a stable package runtime.linux-arm.Microsoft.DotNet.ILCompiler with version (>= 8.0.0)

• Found 3 version(s) in nuget.org [ Nearest version: 9.0.0-preview.1.24080.9 ]
• Found 0 version(s) in /usr/local/share/dotnet/library-packs Restore failed.

Known Workarounds

No workaround; except to not use the PublishAot flag.

Configuration

% dotnet --info .NET SDK: Version: 8.0.100 Commit: 57efcf1350 Workload version: 8.0.204-baseline.24170.37

Runtime Environment: OS Name: Mac OS X OS Version: 13.6 OS Platform: Darwin RID: osx-x64 Base Path: /usr/local/share/dotnet/sdk/8.0.100/

.NET workloads installed: Workload version: 8.0.204-baseline.24170.37 [maui-mobile] Installation Source: SDK 8.0.100 Manifest Version: 8.0.3/8.0.100 Manifest Path: /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.maui/8.0.3/WorkloadManifest.json Install Type: FileBased

Host: Version: 8.0.4 Architecture: x64 Commit: 2d7eea2529

.NET SDKs installed: 5.0.408 [/usr/local/share/dotnet/sdk] 6.0.127 [/usr/local/share/dotnet/sdk] 6.0.419 [/usr/local/share/dotnet/sdk] 6.0.420 [/usr/local/share/dotnet/sdk] 6.0.421 [/usr/local/share/dotnet/sdk] 7.0.116 [/usr/local/share/dotnet/sdk] 7.0.313 [/usr/local/share/dotnet/sdk] 7.0.406 [/usr/local/share/dotnet/sdk] 8.0.100 [/usr/local/share/dotnet/sdk] 8.0.101 [/usr/local/share/dotnet/sdk] 8.0.203 [/usr/local/share/dotnet/sdk] 8.0.204 [/usr/local/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 5.0.17 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.27 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.28 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.29 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.16 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 5.0.17 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.27 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.28 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.29 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.16 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found: None

Environment variables: Not set

global.json file: /private/tmp/Projects/PublishAotError/global.json

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

Other information

No response

[MichalStrehovsky]

Can you run dotnet restore -bl and share the msbuild.binlog file? I don't have a mac.

Not sure how we're ending up trying to restore the linux-arm package. The .NET SDK knows such package doesn't exist. We're adding linux-arm for .NET 9, but a .NET 8 SDK (and a project targeting .NET 8) shouldn't be asking about it.

Cc @ivanpovazan

[ivanpovazan]

msbuild.binlog would be much appreciated, and I will try to repro as well.

[am11]

Known Workarounds

Since ios and linux-bionic runtime packs are still in preview (on nuget.org), I applied this patch with explicit version:

--- a/PublishAotError/PublishAotError.csproj
+++ b/PublishAotError/PublishAotError.csproj
@@ -59,7 +59,7 @@
                <PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiVersion)" />
                <PackageReference Include="Microsoft.Maui.Controls.Compatibility" Version="$(MauiVersion)" />
                <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="8.0.0" />
-<!--           <PackageReference Include="Microsoft.DotNet.ILCompiler" Version="8.0.4" />-->
+               <PackageReference Include="Microsoft.DotNet.ILCompiler;runtime.ios-arm64.Microsoft.DotNet.ILCompiler;runtime.linux-bionic-arm64.Microsoft.DotNet.ILCompiler" Version="8.0.0-preview.6.23329.7" />

and used dotnet publish -f net8.0-ios -r ios-arm64. (no changes needed for global.json)

Once we publish the stable versions of runtime packs, that will resolve the restore issue and align the ios/android targets so we don't need to specify the version-which-exist-in-nugetorg.

[ivanpovazan]

@am11 does your workaround also work from Visual Studio?

I am asking this because by just specifying -r ios-arm64 on the command-line seems to workaround the problem as well.

[am11]

Yes, this patch is enough without -r:

--- a/PublishAotError/PublishAotError.csproj
+++ b/PublishAotError/PublishAotError.csproj
@@ -19,6 +19,8 @@
                <!-- Versions -->
                <ApplicationDisplayVersion>1.0</ApplicationDisplayVersion>
                <ApplicationVersion>1</ApplicationVersion>
+               <RuntimeIdentifier Condition="'$(TargetFramework)'=='net8.0-android'">linux-bionic-arm64</RuntimeIdentifier>
+               <RuntimeIdentifier Condition="'$(TargetFramework)'=='net8.0-ios'">ios-arm64</RuntimeIdentifier>

                <SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">11.0</SupportedOSPlatformVersion>
                <SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">21.0</SupportedOSPlatformVersion>
@@ -30,7 +32,6 @@
                <CreatePackage>true</CreatePackage>
            <MtouchUseLlvm>true</MtouchUseLlvm>
            <PublishAot>true</PublishAot>
-               <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
     </PropertyGroup>

        <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">

VS for Mac is retiring on August 31, 2024 (in favor of DevKit+VSCode). I haven't installed it. :)

[ivanpovazan]

Thank you @am11

@b12kab can you try the workaround suggested in https://github.com/dotnet/runtime/issues/100929#issuecomment-2051553433 to unblock you in your work?

---

Nevertheless, I think we should investigate how we can avoid restoring packages for net8.0-android in case of NativeAOT in general.

[am11]

Nevertheless, I think we should investigate how we can avoid restoring packages for net8.0-android in case of NativeAOT in general.

Agreed. It was also trying to restore linux-arm package. 😅 Looks like when TFM has TPI (-ios / -android identifier) specified, it tries to restore many unrelated things and user has to specify -r. Ideally TFM, after decomposing to TFI (NetCoreApp) and TPI (iOS), should set the RuntimeIdentifier implicitly and nuget should not try to download unrelated stuff. The dump from dotnet publish -f net8.0-ios -v:diag > dump does show we it's setting RID, but for some reason nuget restore is not respecting it.

[MichalStrehovsky]

It used to be that one always had to specify -r for selfcontained publish. In .NET 8, the SDK tries to infer it somewhere around here:

https://github.com/dotnet/sdk/blob/16cc30eb15fc955b61d11e56e75afa3fc9329b6a/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets#L87-L110

I wonder if the issue is with this logic.

But also, this is essentially a crossbuild so maybe this should error out somewhere asking people to specify the RID manually. We might not be able to infer a good one.

[ivanpovazan]

When -r is not specified, during the build of the restore graph the following target gets called:

https://github.com/dotnet/sdk/blob/16cc30eb15fc955b61d11e56e75afa3fc9329b6a/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.CrossTargeting.targets#L36-L75

which collects all runtime identifiers based on TargetFrameworks specified in the project file, which later causes restoring non-existing packages. (seems like a safety mechanism "restore all as we don't know what we will need")

[b12kab]

I've updated the sample adding the reference noted here, except to place it in an if enclosure that should only be picked up by an iOS release build, just like the PublishAot

I should have put the command line build that I used which is: dotnet publish -f net8.0-ios -c Release (as the include is only done for a iOS release build).

I've uploaded the requested binlog

Using the command line build, I get this error:

PublishAotError -> /private/tmp/Projects/publishaotproblem/PublishAotError/bin/Release/net8.0-ios/ios-arm64/PublishAotError.dll Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink Optimizing assemblies for size. This process might take a while. ~/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/build/Microsoft.DotNet.ILCompiler.SingleEntry.targets(46,5): warning : Delete explicit 'Microsoft.DotNet.ILCompiler' package reference in your project file to avoid versioning problems. [/private/tmp/Projects/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] Generating native code /var/folders/lz/lnqytr310p7_8czr7lct3wb00000gp/T/MSBuildTempkeithbeatty/tmpa17e610117594af9aa77699320c9db15.exec.cmd: line 2: \tools\ilc: command not found ~/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/build/Microsoft.NETCore.Native.targets(290,5): error MSB3073: The command ""\tools\ilc" @"obj/Release/net8.0-ios/ios-arm64/native/PublishAotError.ilc.rsp"" exited with code 127. [/private/tmp/Projects/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] log.zip

[ivanpovazan]

@b12kab thank you for providing the binlog.

Sorry for the confusion about the workarounds. Can you try the following:

1. Use your initial setup and from terminal run: dotnet publish -f net8.0-ios -r ios-arm64
   • This should work without any changes to your project

2. If 1) doesn't work, could you try adjusting your .csproj file with:

   --- a/PublishAotError/PublishAotError.csproj
   +++ b/PublishAotError/PublishAotError.csproj
   @@ -19,6 +19,8 @@
                   <!-- Versions -->
                   <ApplicationDisplayVersion>1.0</ApplicationDisplayVersion>
                   <ApplicationVersion>1</ApplicationVersion>
   +               <RuntimeIdentifier Condition="'$(TargetFramework)'=='net8.0-android'">linux-bionic-arm64</RuntimeIdentifier>
   +               <RuntimeIdentifier Condition="'$(TargetFramework)'=='net8.0-ios'">ios-arm64</RuntimeIdentifier>
   
                   <SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">11.0</SupportedOSPlatformVersion>
                   <SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">21.0</SupportedOSPlatformVersion>
   @@ -30,7 +32,6 @@
                   <CreatePackage>true</CreatePackage>
               <MtouchUseLlvm>true</MtouchUseLlvm>
               <PublishAot>true</PublishAot>
   -               <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
       </PropertyGroup>
   
           <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">

   and then publish it with: dotnet publish -f net8.0-ios -c Release or from Visual Studio

[b12kab]

1) Didn't work. Last few lines of build: Optimizing assemblies for size. This process might take a while. ~/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/build/Microsoft.DotNet.ILCompiler.SingleEntry.targets(46,5): warning : Delete explicit 'Microsoft.DotNet.ILCompiler' package reference in your project file to avoid versioning problems. [/private/tmp/Projects/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] Generating native code /var/folders/lz/lnqytr310p7_8czr7lct3wb00000gp/T/MSBuildTempkeithbeatty/tmpb819487f317f416188e85ea2849398ce.exec.cmd: line 2: \tools\ilc: command not found ~/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.0-preview.6.23329.7/build/Microsoft.NETCore.Native.targets(290,5): error MSB3073: The command ""\tools\ilc" @"obj/Release/net8.0-ios/ios-arm64/native/PublishAotError.ilc.rsp"" exited with code 127. [/private/tmp/Projects/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios]

2) made change as requested

3) Tried build and failed with same error lines as on 1

[MichalStrehovsky]

8.0.0-preview.6.23329.7

Where is this version coming from? This is some very old pre-release version (it's a year old build). Can you delete any explicit ILCompiler package references you have in the project file, delete obj and bin directories, and run dotnet publish -f net8.0-ios -r ios-arm64?

[am11]

8.0.0-preview.6.23329.7

Where is this version coming from? This is some very old pre-release version (it's a year old build).

https://www.nuget.org/packages/runtime.ios-arm64.Microsoft.DotNet.ILCompiler#versions-body-tab

/var/folders/lz/lnqytr310p7_8czr7lct3wb00000gp/T/MSBuildTempkeithbeatty/tmpb819487f317f416188e85ea2849398ce.exec.cmd: line 2: \tools\ilc: command not found

The confusing part is why is it calling .cmd script on macOS on that machine. Maybe something is off in obj/. Try closing the VS and running git clean -xdf before retrying.

[MichalStrehovsky]

8.0.0-preview.6.23329.7

Oh, I see, this version is in the project file:

    <ItemGroup Condition="$(TargetFramework.Contains('ios'))">
        <PackageReference Include="Microsoft.DotNet.ILCompiler;runtime.ios-arm64.Microsoft.DotNet.ILCompiler;runtime.linux-bionic-arm64.Microsoft.DotNet.ILCompiler" Version="8.0.0-preview.6.23329.7" />
    </ItemGroup>

We don't ship runtime.ios-arm64.Microsoft.DotNet.ILCompiler;runtime.linux-bionic-arm64.Microsoft.DotNet.ILCompiler. The reason why only 8.0.0-preview.6.23329.7 exists on nuget is because we stopped producing these ILCompiler packages once we started making runtime packs (there's no ios-arm64 hosted ILCompiler). It's not the correct package to reference. Delete the entire PackageReference line and instead dotnet publish -f net8.0-ios -r ios-arm64. The project probably became more broken by adding references to these point-in-time development packages.

[am11]

Yeah it was either https://github.com/dotnet/runtime/issues/100929#issuecomment-2051481085 "or" https://github.com/dotnet/runtime/issues/100929#issuecomment-2051553433 (both fix the compilation error individually). The OP has applied both.

[b12kab]

Removing the additional nuget worked, but gets warnings (see below) with both commands:

• dotnet publish -f net8.0-ios -c Release
• dotnet publish -f net8.0-ios -r ios-arm64 -c Release

What about removing the RuntimeIdentifier from the iOS conditional compile PropertyGroup allowed this to work?

/private/tmp/publishaotproblem/PublishAotError/obj/Release/net8.0-ios/ios-arm64/linked/Microsoft.iOS.dll : warning IL3053: Assembly 'Microsoft.iOS' produced AOT analysis warnings. [/private/tmp/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] /private/tmp/publishaotproblem/PublishAotError/obj/Release/net8.0-ios/ios-arm64/linked/Microsoft.Maui.Controls.Xaml.dll : warning IL2104: Assembly 'Microsoft.Maui.Controls.Xaml' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries [/private/tmp/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] /private/tmp/publishaotproblem/PublishAotError/obj/Release/net8.0-ios/ios-arm64/linked/Microsoft.Maui.Controls.Xaml.dll : warning IL3053: Assembly 'Microsoft.Maui.Controls.Xaml' produced AOT analysis warnings. [/private/tmp/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] /private/tmp/publishaotproblem/PublishAotError/obj/Release/net8.0-ios/ios-arm64/linked/Microsoft.Maui.Controls.dll : warning IL2104: Assembly 'Microsoft.Maui.Controls' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries [/private/tmp/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] /private/tmp/publishaotproblem/PublishAotError/obj/Release/net8.0-ios/ios-arm64/linked/Microsoft.Maui.dll : warning IL2104: Assembly 'Microsoft.Maui' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries [/private/tmp/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios] /private/tmp/publishaotproblem/PublishAotError/obj/Release/net8.0-ios/ios-arm64/linked/Microsoft.Maui.dll : warning IL3053: Assembly 'Microsoft.Maui' produced AOT analysis warnings. [/private/tmp/publishaotproblem/PublishAotError/PublishAotError.csproj::TargetFramework=net8.0-ios]

[am11]

dotnet publish -f net8.0-ios -c Release

This is enough, now that csproj has RuntimeIdentifier. When I collected the -v:diag dump, I saw that RuntimeIdentifier is correctly set by the SDK but then somewhere it gets lost. I didn't investigated why. I think we should fix it because SDK has assumed responsibility of setting RID for all platforms and this seems like an anomaly. I'll try to figure it out in my spare time.

but gets warnings

That's a separate issue. Some warnings are ignorable others aren't, you would need to test the published app on the device/emulator to make sure whether or not it's safe to ignore these. In any case, those should be reported in their corresponding downstream repos (such as https://github.com/dotnet/maui/issues, if there isn't an issue already tracking it).

[b12kab]

@am11 Yes, please. I'm unsure if I can move the setting outside of the conditional compile, as the original project looks at the active configuration to choose between arm-ios64 and iossimulator-x64.

Thank you all for your help.

[am11]

Actual behavior

Error on restore (or build if done without restore).

Could you show this error?

[ivanpovazan]

Glad it worked and that you are able to build your app.

---

Regarding your question:

What about removing the RuntimeIdentifier from the iOS conditional compile PropertyGroup allowed this to work?

If the runtime identifier is unknown during dotnet restore i.e., not specified on the command line, dotnet restore will try to resolve and get all the dependencies needed for targeting all target frameworks specified in the project file. Since net8.0-android is not supported with NativeAOT, it tries to fetch a package that does not exist for .NET8 (in your case that was: runtime.linux-arm.Microsoft.DotNet.ILCompiler).

By specifying:

<RuntimeIdentifier Condition="'$(TargetFramework)'=='net8.0-android'">linux-bionic-arm64</RuntimeIdentifier>

we just tricked dotnet restore in its resolution process, by specifying that linux-bionic-arm64 would be the runtime identifier if someone would target android with NativeAOT. This trick works as we do ship Microsoft.NETCore.App.Runtime.NativeAOT.linux-bionic-arm64 in .NET8.

Your configuration for ios was correct, the problem is on our end with multi-targeting which you had to work around.

---

Regarding the trim and AOT warnings that you get. They are indication that the MAUI framework and/or your app is not fully compatible with NativeAOT. As long as there are trim/AOT warnings during the build, there is no guarantee that the app will work correctly in all cases during runtime with NativeAOT. It might work, but it could also crash depending on the use case. We are actively working on solving these problems in the upcoming releases with MAUI and you can check https://github.com/dotnet/maui/issues/19397 and https://github.com/dotnet/maui/issues/18658 to track the progress.

[am11]

@ivanpovazan, in the original repro, this is the error I received for net8.0-ios:

% dotnet publish -f net8.0-ios
MSBuild version 17.9.6+a4ecab324 for .NET
  Determining projects to restore...
/Users/am11/projects/publishaotproblem/PublishAotError/PublishAotError.csproj : error NU1103: Unable to find a stable package runtime.linux-arm.Microsoft.DotNet.ILCompiler with version (>= 8.0.3) [/Users/am11/projects/publishaotproblem/PublishAotError.sln]
/Users/am11/projects/publishaotproblem/PublishAotError/PublishAotError.csproj : error NU1103:   - Found 411 version(s) in dotnet9 [ Nearest version: 9.0.0-alpha.1.24069.7 ] [/Users/am11/projects/publishaotproblem/PublishAotError.sln]
/Users/am11/projects/publishaotproblem/PublishAotError/PublishAotError.csproj : error NU1103:   - Found 3 version(s) in nuget.org [ Nearest version: 9.0.0-preview.1.24080.9 ] [/Users/am11/projects/publishaotproblem/PublishAotError.sln]
/Users/am11/projects/publishaotproblem/PublishAotError/PublishAotError.csproj : error NU1103:   - Found 0 version(s) in /usr/local/share/dotnet/library-packs [/Users/am11/projects/publishaotproblem/PublishAotError.sln]
/Users/am11/projects/publishaotproblem/PublishAotError/PublishAotError.csproj : error NU1103:   - Found 0 version(s) in dotnet8 [/Users/am11/projects/publishaotproblem/PublishAotError.sln]
  Failed to restore /Users/am11/projects/publishaotproblem/PublishAotError/PublishAotError.csproj (in 819 ms).

That error is about linux-arm because nuget client searches for all runtime.json files, collects all entries in those files and tries to restore for all platforms matching the TPI https://github.com/NuGet/NuGet.Client/blob/95b79314dfece146ddcbac902111d9ff946cf514/src/NuGet.Core/NuGet.Commands/RestoreCommand/ProjectRestoreCommand.cs#L458. If you open runtime.json in https://nuget.info/packages/Microsoft.DotNet.ILCompiler/8.0.3, you will see linux-arm on line 15, which is wrong because that runtime does not exist. If i delete just that linux-arm block from ~/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.3/runtime.json, it starts to build. So this suggests it's our runtime packaging bug?

[MichalStrehovsky]

If i delete just that linux-arm block from ~/.nuget/packages/microsoft.dotnet.ilcompiler/8.0.3/runtime.json, it starts to build. So this suggests it's our runtime packaging bug?

Yes, looks like it. A linux-arm entry was added in https://github.com/dotnet/runtimelab/pull/1530 last time ARM32 support in native AOT was attempted, but it was not finished at that time. This line needs to be deleted in release/8.0 branch:

https://github.com/dotnet/runtime/blob/8966d0885f9bca07b7b9588cbfee04398a17e83a/src/installer/pkg/projects/Microsoft.DotNet.ILCompiler/ILCompilerRIDs.props#L5

(It should not be deleted in main, because we now do have linux-arm support in 9.0.)

@ivanpovazan do you have a sense of how common this situation could be - whether we need to service this? I don't think it affects the non-device scenarios - we had this bug since 7.0 and this is the first time we're hearing about it.

[ivanpovazan]

@am11 sorry for the delayed answer and thanks for pointing it out. Yes, that does seem like the problem.

However, I also wanted to bring attention to the fact that if we take the project, open it in Visual Studio for Mac and do publish, the VS will initiate:

/usr/local/share/dotnet/dotnet publish "/Users/ivan/tmp/MauiNet8VS/MauiNet8VS.csproj" --configuration "Release" --framework "net8.0-ios" --output "bin/Release/net8.0-ios/publish"

Under the hood, it first calls restore target (-target:Restore) which ignores the passed framework and instead does a restore for every TFM specified in the project file (which triggers the problem you found).

My concern is more general and I am trying to figure out how our tools are initiating publish in different scenarios, especially in cases when a certain deployment model (NativeAOT) does not support a certain TFM (net8.0-android) but is specified in a multi-targeted project file, and can we disable it. Specifying runtime identifier makes dotnet restore to take it into account, but is not passed from VS.

@MichalStrehovsky, what I described above basically means that MAUI project cannot be published from Visual Studio for Mac with .NET8 and NativeAOT

[ivanpovazan]

The fix has been merged and will become available in the next servicing release.

[MichalStrehovsky]

The fix has been merged and will become available in the next servicing release.

Thank you! Do we need to keep this open to track something left?

[ivanpovazan]

The fix has been merged and will become available in the next servicing release.

Thank you! Do we need to keep this open to track something left?

My intention was to close it once it is officially available and we do a E2E test. However, if you think we can do that now and potentially reopen it if the problem persists, feel free to do so :)

[MichalStrehovsky]

My intention was to close it once it is officially available and we do a E2E test.

Sure, if you don't forget to do that, go for that. My experience is that people forget and the issue will linger open for years.

[eerhardt]

Can this be closed now?

[ivanpovazan]

Can this be closed now?

The last servicing release did not include the fix. As I previously mentioned, I will close the issue once the fix is publicly available and was verified that E2E scenario works.

[ivanpovazan]

The fix is included in the latest release of dotnet 8.0.7 (SDK 8.0.303) and it has been verified that the project can be successfully published for iOS from Visual Studio.