Localization not work under iOS and Mac arm64

[rolfbjarne]

From @changguangyu on Fri, 18 Nov 2022 13:22:22 GMT

Description

Localization not work under iOS and Mac arm64.
It seems that <GenerateSatelliteAssembliesForCore>true</GenerateSatelliteAssembliesForCore> under these platform is broken.
The satellite assemblies are not included in output app package.

Right click 'Show package contents' on output Mac app, the satellite assemblies folder(e.g. zh-Hans) inside MonoBundle directory are empty. There should be ProjectName.resources.dll.

Steps to Reproduce

1. Clone this project https://github.com/VladislavAntonyuk/MauiSamples/tree/main/MauiLocalization
2. Compile with Visual Studio 17.4 with .Net 7.0

For Windows and Android, switch language is working fine, but on iOS and Mac arm64 it's not work.

The satellite assemblies are not included in output app package.

It seems that <GenerateSatelliteAssembliesForCore>true</GenerateSatelliteAssembliesForCore> is broken.

Link to public reproduction project repository

https://github.com/VladislavAntonyuk/MauiSamples/tree/main/MauiLocalization

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS, macOS

Affected platform versions

Mac x64 is working fine, arm not work

Did you find any workaround?

No response

Relevant log output

No response

Copied from original issue dotnet/maui#11474

[rolfbjarne]

From @rachelkang on Fri, 18 Nov 2022 15:05:14 GMT

@rolfbjarne thoughts?

[rolfbjarne]

From @rolfbjarne on Fri, 18 Nov 2022 16:11:40 GMT

@changguangyu

Right click 'Show package contents' on output Mac app, the satellite assemblies folder(e.g. zh-Hans) inside MonoBundle directory are empty. There should be ProjectName.resources.dll.

Your test project doesn't seem to contain any zh-Hans resources, but it contains a uk resource, which shows up in the uk subdirectory in the app bundle (for iOS apps) when I build on macOS using the command line:

MauiLocalization.app/uk/MauiLocalization.resources.dll

does it work for you if you build from the command line? If not, can you get a binary buildlog so that we can investigate where things go wrong for you?

[rolfbjarne]

From @changguangyu on Sat, 19 Nov 2022 00:57:53 GMT

This is my build command: dotnet build -f:net7.0-maccatalyst -c:Release /bl:msbuild.binlog

The uk subdirectory at bin/Release/net7.0-maccatalyst/maccatalyst-x64/MauiLocalization.app/Contents/MonoBundle/uk is fine. But bin/Release/net7.0-maccatalyst/MauiLocalization.app/Contents/MonoBundle/uk is empty.

Here is my build log.
msbuild.binlog.zip

[rolfbjarne]

From @changguangyu on Mon, 21 Nov 2022 01:01:56 GMT

The issue also exists in iOS App Store distribution package(but does not appear when test the app in both debug and release mode, physical device and stimulator). I think MAUI is not a proper choice for production at this time. Not because bugs of MAUI, but the difference between the final distribution package and release mode package, which makes MAUI totally not reliable.

[rolfbjarne]

From @changguangyu on Mon, 21 Nov 2022 03:09:28 GMT

Edit: Tested again. On iOS App Store distribution package it is another issue. uk folder is not empty, but switch language not work.

[rolfbjarne]

From @changguangyu on Mon, 21 Nov 2022 05:18:45 GMT

Still cannot solve this issue.

[rolfbjarne]

From @changguangyu on Mon, 21 Nov 2022 05:41:10 GMT

Temporary Fix for Mac: Add <RuntimeIdentifiers>maccatalyst-x64</RuntimeIdentifiers> to force build a x64 only Mac package( Prevent build universal package for x64 and arm64).

[rolfbjarne]

I can reproduce the problems when building a universal Mac Catalyst app (which is now the default for Release builds).

There are at least two factors contributing to the problem:

1. The default for EnableAssemblyILStripping is different between maccatalyst-x64 and maccatalyst-arm64, which leads to only one of the MauiLocalization.resources.dll assemblies to be stripped, which makes them different, and as such they can't both be put in the expected location.
2. The MauiLocalization.dll assemblies are also different (even when EnableAssemblyILStripping is set to false for both RIDs), which causes the dependent MauiLocalization.resources.dll to be treated as different as well. This is because of the /debug:portable flag passed to csc (probably due to paths embedded in the debug info)
3. The MauiLocalization.dll is still different when disabling debug info (<DebugType>none</DebugType>, because the /platform:... flag to csc is different. This can be fixed by setting <PlatformType>AnyCPU</PlatformType>.
4. The MauiLocalization.dll is still different even after using AnyCPU as the platform type. I haven't been able to figure out why yet, because if I copy the csc command from the binlog I get a different binary (and they're identical between x64 and arm64), so maybe there's an environment variable during the build that changes how csc creates assemblies.

Things we'll probably need to do:

1. Make EnableAssemblyILStripping default to the same value for universal builds.
2. Figure out a way to make resource assemblies load properly when they're different for each platform for universal builds.

[rolfbjarne]

1. Make EnableAssemblyILStripping default to the same value for universal builds.

I've moved this to its own issue: #17115.