AL1012: 'arm64' is not a valid setting for option 'platform'

[rolfbjarne]

Describe the bug

When building a project:

• Using Visual Studio
• It has localized resources
• It targets an arm64 platform

This error happens:

AL1012: 'arm64' is not a valid setting for option 'platform'

To Reproduce

https://github.com/ewerspej/dotnet-maui-bug-repro-ios-arm64

This comes from: dotnet/macios#16193

This is an iOS project, and it might be easier to create a sample project using this stackoverflow post with the same problem: https://stackoverflow.com/questions/71378075/publish-to-arm64-not-working-when-cultured-resx-file-added

Exceptions (if any)

AL1012: 'arm64' is not a valid setting for option 'platform'

Further technical details

A binlog is available here: https://github.com/ewerspej/dotnet-maui-bug-repro-ios-arm64/blob/main/bug-ios-arm64/bug-ios-arm64_Debug_AnyCPU_net7.0-ios_Build_2022-10-10T09_34_03.0519455%2B02_00.zip

Version: .NET 7.0.100-rc.1.22431.12 (according to dotnet/macios#16193).

Analysis

(copied from dotnet/macios#16193 (comment))

I think I know what's going on.

When building using either VSMac or the command line (either from Windows or Mac), the MSBuildRuntimeType property is set to Core.

as a result, the default value for GenerateSatelliteAssembliesForCore is true:

<GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore>

Ref:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets

Line 41 in 0010096

<GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore>

Looks like this logic comes from here:

2506af1

However, when building from inside Visual Studio (for Windows), the MSBuildRuntimeType property is set to Full, and thus GenerateSatelliteAssembliesForCore is not set to true, and we end up executing al.exe to generate satellite assemblies, which is wrong.

It seems to me that the problem is the logic to determine whether al.exe should be used or not, it shouldn't depend on where MSBuild is executing, but instead what kind of project is being built.

[marcpopMSFT]

@dsplaisted let's chat when you're back to understand more about this.

[IgorKravchenko10]

I am trying to build my project and get this error too in Visual Studio 17.4.0 Preview 5.0
Here is the sample. I just added Translator.resx, Translator.uk.resx, Translator.ru.resx to project and now unable to compile in release mode.
MauiApp1.zip

All works after adding
<GenerateSatelliteAssembliesForCore>true</GenerateSatelliteAssembliesForCore>
to project file.

[marcpopMSFT]

@rainersigwald Do you know who owns Al.exe and if it supports arm64? Is setting that property the appropriate workaround here?

[dsplaisted]

We only set GenerateSatelliteAssembliesForCore when MSBuildRuntimeType is Core:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets

Line 41 in ee90746

<GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore>

We should probably expand the condition to use it went not targeting full .NET Framework, or when targeting ARM, or something.

[benvillalobos]

We should probably expand the condition to use it went not targeting full .NET Framework, or when targeting ARM, or something.

If the tool doesn't support ARM, the condition to stop it from running should be based on arm until it gets arm64 support imo

[Forgind]

Don't we own AL.exe? We have an AL task, and looking at that, it was last touched by BenVillalobos in adding platform support (then me in fixing a nre), not including style things. It seems to have explicit support for x86 and x64, but then falls back to the "CurrenProcessArchitecture", so we might just have to add ARM as an option.

[benvillalobos]

@Forgind We don't, our AL task is a tooltask that shells out to Al.exe. The error code AL1012 shows the tool ran but was passed a flag it didn't support.

It seems to have explicit support for x86 and x64, but then falls back to the "CurrenProcessArchitecture", so we might just have to add ARM as an option.

My change added a check for which version of Al.exe to call (32 bit or 64 bit), not support for a new platform within the tool. Adding an arm64 check in our task wouldn't resolve this particular issue.

[dsplaisted]

If GenerateSatelliteAssembliesForCore is set, then we use the Csc task instead of AL.exe to generate the satellite assemblies.

Does AL.exe have any capabilities that the Roslyn compilers wouldn't? Is there any reason to keep using AL.exe over Roslyn for projects that aren't targeting .NET Framework? (In any case, we already use Roslyn for dotnet build, just not full Framework msbuild.

[AArnott]

This is blocking our upgrade to using the .NET 7 SDK. It looks like a lot of talk about has to do with this specific case, but it's very general. The only thing you need to repro is a vanilla C# class library project that has non-default culture resources that includes an arm64 target.

Repro

1. Unzip this: ClassLibrary2.zip
2. Build the arm64 platform.

I believe the regression came because of adding arm64 targeting support to the SDK:

But the GenerateSatelliteAssemblies target consumes $(PlatformTarget) property and passes it the al.exe, which doesn't consider arm64 to be a valid platform.

[marcpopMSFT]

@AArnott can you not set GenerateSatelliteAssembliesForCore to work around this? Per Daniel above, our fix for this is going to be setting that property when targeting core and I want to confirm that that's enough to unblock you.

[marcpopMSFT]

Not sure if setting this only targeting core will be enough since 481 supports arm64. Chat with Daniel

[AArnott]

Exactly right: my project isn't actually targeting .NET. It's targeting .NET Framework.

[dsplaisted]

Even if you're targeting .NET Framework, I believe that GenerateSatelliteAssembliesForCore will work for you.

[AArnott]

Thanks. I already devised a different workaround though.