[.NET 8] Mono workload doesn't import Microsoft.NET.Runtime.MonoAOTCompiler.Task

Description

It appears that building a net7.0-android project with a .NET 8 SDK skips this import:

<!-- ======== C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\sdk-manifests\8.0.200\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.targets ======= -->
<Project>
    <Import Condition="'$(TargetsNet7)' == 'true' and '$(RunAOTCompilation)' == 'true' and '$(UsingBrowserRuntimeWorkload)' == 'true'" Project="Sdk.props" Sdk="Microsoft.NET.Runtime.MonoAOTCompiler.Task.net7" />

And then a Release build with AOT happens to work, because we have these imports as a fallback:

https://github.com/xamarin/xamarin-android/blob/fb636843e9661599a8a2cf070cb101b4a946513b/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.Aot.targets#L19-L31

(We're wanting to remove these imports from .NET 8, and stop supporting the $(AotAssemblies) brought forward from Xamarin.Android)

The end result is several build warnings, such as:

Warnings
    C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.1\targets\Microsoft.Android.Sdk.Aot.targets(27,5): warning MSB4011: "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.android-x86\8.0.0-alpha.1.22507.5\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\sdk-manifests\8.0.200\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.targets (9,9)". This is most likely a build authoring error. This subsequent import will be ignored. [C:\a\_work\1\a\TestRelease\10-22_07.31.58\temp\DotNetPublishTrue[net7.0 android 33]\UnnamedProject.csproj]
    C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.1\targets\Microsoft.Android.Sdk.Aot.targets(28,5): warning MSB4011: "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.android-x64\8.0.0-alpha.1.22507.5\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\sdk-manifests\8.0.200\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.targets (10,9)". This is most likely a build authoring error. This subsequent import will be ignored. [C:\a\_work\1\a\TestRelease\10-22_07.31.58\temp\DotNetPublishTrue[net7.0 android 33]\UnnamedProject.csproj]
    C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.1\targets\Microsoft.Android.Sdk.Aot.targets(29,5): warning MSB4011: "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.android-arm\8.0.0-alpha.1.22507.5\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\sdk-manifests\8.0.200\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.targets (11,9)". This is most likely a build authoring error. This subsequent import will be ignored. [C:\a\_work\1\a\TestRelease\10-22_07.31.58\temp\DotNetPublishTrue[net7.0 android 33]\UnnamedProject.csproj]
    C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.1\targets\Microsoft.Android.Sdk.Aot.targets(30,5): warning MSB4011: "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.android-arm64\8.0.0-alpha.1.22507.5\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\sdk-manifests\8.0.200\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.targets (12,9)". This is most likely a build authoring error. This subsequent import will be ignored. [C:\a\_work\1\a\TestRelease\10-22_07.31.58\temp\DotNetPublishTrue[net7.0 android 33]\UnnamedProject.csproj]

But I think the core problem might be $(UsingBrowserRuntimeWorkload) isn't set?

Reproduction Steps

Install .NET 8 and the Android workload
dotnet new android, then change TFM to net7.0-android
dotnet build -c Release -bl

See the warnings in the build log.

Actual behavior

Building net7.0-android apps with the .NET 8 SDK emits build warnings.

Expected behavior

Building net7.0-android apps with the .NET 8 SDK should have no build warnings.

Regression?

It works to multitarget .NET 7 SDK, building net6.0-android apps, so yes?

Known Workarounds

Targeting net8.0-android and net6.0-android with the .NET 8 SDK appear to work.

Configuration

.NET SDK 8.0.200-alpha.1.22511.1
.NET runtime 8.0.0-alpha.1.22507.5

Other information

.binlog: dotnet8-7-multitargeting.zip

Remove a net7.0 assertion for build warnings

@lewing

cc @lewing @steveisok
I will also take a look later today.

We didn't really need a property for mobile previously, but I think that would simplify the fix for this.

Bump to .NET 8

[Workloads] Add UsingMobileWorkload property to control loading net7 …

Bump to dotnet/installer@d5520378 8.0.200-alpha.1.22511.1 (#7451)

We hit another error related to this problem, building a net7.0-android app with a .NET 8 SDK:

Microsoft.Android.Sdk.RuntimeConfig.targets(46,5): error MSB4036: The "RuntimeConfigParserTask" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/8.0.100-alpha.1.22526.2" directory.

Logs: runtimeconfigparser.zip

This fix doesn't appear to work, because the .NET 8 .targets are imported last?

Maybe we can't rely on this having a stable order, and you have to make the same check in all three WorkloadManifests.targets files?

Here is a .binlog: net7onnet8.zip

This failed here: dotnet/android#7505

Weird, in the sdk I'm using, it comes in the right order.

My SDK version is 8.0.100-alpha.1.22531.1

What happens when the name changes to microsoft.net.workload.mono.toolchain.net8, will it move to the bottom?

I don't know how much you can rely on the ordering, but we could ask the .NET SDK team?

[tests] temporarily ignore net6.0 and net7.0 tests

@dsplaisted

dotnet/sdk#28607 makes things right, but only for .NET 7 it seems.

@dsplaisted did this go into the .NET 8 SDK yet?

What happens when the name changes to microsoft.net.workload.mono.toolchain.net8, will it move to the bottom?

As long as the SDK current baseline manifest targets run first, I don't think it'll matter what net* workload targets load.

[xaprepare] use 8.0.100 version band for Mono workloads

@dsplaisted

dotnet/sdk#28607 makes things right, but only for .NET 7 it seems.

@dsplaisted did this go into the .NET 8 SDK yet?

It had not gone into main yet. I've just merged dotnet/sdk#28875, so now it is in main (pending code flow and builds of course).

I think this also will fix the ordering for us: dotnet/android#7530

Parts of our build moves files around manually, so we had sdk-manifests/8.0.100-alpha.1 instead of 8.0.100.

[xaprepare] use 8.0.100 version band for Mono workloads (#7530)

This appeared to be fixed by dotnet/android#7530, our build has to do manual things with workloads, so it can build against the abstract Mono workload.

I don't think the ordering issue would have happened when installing workloads normally.

Navigation Menu

Repository navigation

[.NET 8] Mono workload doesn't import Microsoft.NET.Runtime.MonoAOTCompiler.Task #77385

Description

Reproduction Steps

Actual behavior

Expected behavior

Regression?

Known Workarounds

Configuration

Other information

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[.NET 8] Mono workload doesn't import Microsoft.NET.Runtime.MonoAOTCompiler.Task #77385

Description

Description

Reproduction Steps

Actual behavior

Expected behavior

Regression?

Known Workarounds

Configuration

Other information

Activity

radical commented on Oct 24, 2022

steveisok commented on Oct 24, 2022

jonathanpeppers commented on Oct 31, 2022

4 remaining items

jonathanpeppers commented on Nov 4, 2022

steveisok commented on Nov 4, 2022

jonathanpeppers commented on Nov 4, 2022

steveisok commented on Nov 4, 2022

steveisok commented on Nov 4, 2022

dsplaisted commented on Nov 4, 2022

jonathanpeppers commented on Nov 4, 2022

jonathanpeppers commented on Nov 7, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions