-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MacCatalyst] Failure to run in release mode (arm64) #24404
Comments
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! Open similar issues:
Closed similar issues:
|
I've investigated this some more and found that I need to remove the bin and obj directories every time before running the app in release mode. The
command is not enough to make it work. We were interested because we would get to the login page, which would fail on arm64 but not x64. There is a reason for that, which I highlight in the following comment. I added a version number/architecture string on the login page. Having built a new pkg file for TestFlight, it deploys to the MacBook Air M1 as expected. However, when I run it, it shows X64 as the architecture, and to provide the point, it logs in. Deploying it through TestFlight on my i9 Mac works as expected. Why does it misidentify the architecture and work appropriately as X64? Getting rid of some apps referenced with the same name from LaunchPad and a reinstall from TestFlight got round the problem. It now shows as arm64. |
I extended the logging (Serilog run through Microsoft Extensions.Logging) to trap any issues I could find when accessing the database. I'm using AutoMapper here. When running locally on the MacBook Air M1, I have an error in the log that does not appear on X64 (which runs as expected). 2024-08-25 09:57:18.887 +01:00 [ERR] Could not read organisation: Attempting to JIT compile method '(wrapper dynamic-method) SharedCommon.Models.Authorisation.Organisation.Organisation object:Thunk1ret_Organisation_Object_Organisation_ResolutionContext (System.Func`2<object[], object>,object,SharedCommon.Models.Authorisation.Organisation.Organisation,AutoMapper.ResolutionContext)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information. System.ExecutionEngineException: Attempting to JIT compile method '(wrapper dynamic-method) SharedCommon.Models.Authorisation.Organisation.Organisation object:Thunk1ret_Organisation_Object_Organisation_ResolutionContext (System.Func`2<object[], object>,object,SharedCommon.Models.Authorisation.Organisation.Organisation,AutoMapper.ResolutionContext)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information. at System.Delegate.CreateDelegate(Type type, Object firstArgument, MethodInfo method, Boolean throwOnBindFailure, Boolean allowClosed) |
I have the interpreter turned on to use Automapper with iOS, which works already. I've now turned it on for Mac, too, allowing me to run the app locally on the MacBook Air M1. I've created a new package for Mac and uploaded it to TestFlight. It works on both arm64 and x64 when deployed. |
The mono interpreter seems like a blunt instrument. Short of hard coding the class mappings or turning on the interpreter, is there an alternative approach to explore? |
@sumowesley I would ask Automapper how they would suggest handling AOT use cases like this and see if it has ways to. Otherwise, the path of least resistance would probably be to enable the Mono Interpreter. MAUI UI Debug builds enable the Interpreter by default (hence why you wouldn't see this until Release mode, non-MAUI UI .NET iOS/Mac Catalyst Template apps don't have it enabled in Debug mode) I don't think this is a MAUI UI or, as far as I can see, a runtime one. You would either enable the Interpreter or use libraries/write code that play well with AOT. @rolfbjarne What do you think? |
@drasticactions, that's a fair suggestion. I can't get over the fact that this worked on x64 with no interpreter active. |
That's because there's no AOT compilation on x64, it's all JIT compilation, which works fine. Note that you can fine tune the interpreter by enabling or disabling it on an assembly basis: https://learn.microsoft.com/en-us/dotnet/maui/macios/interpreter?view=net-maui-8.0 |
Hi @rolfbjarne , I'll explore the link you shared to see if I can get away with the interpreter in place for just AutoMapper |
I'll close this one for now. Thanks to everybody for their help. |
Description
When I run my .NET MAUI app on the MacBook Air M1, it crashes almost immediately. This crash happens when the app runs in Release mode from the command line or when TestFlight installs it on the device. Release mode on my x64 Mac works fine from the command line and via TestFlight.
The iOS version of the app deploys OK via TestFlight.
Steps to Reproduce
TestFlight method
Local command line method
dotnet clean
dotnet build -f net8.0-maccatalyst -c Release
dotnet run --no-launch-profile -f net8.0-maccatalyst -c Release
Link to public reproduction project repository
No response
Version with bug
8.0.80 SR8
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
macOS
Affected platform versions
Sonoma 14.6.1,
Did you find any workaround?
No response
Relevant log output
The text was updated successfully, but these errors were encountered: