maui
maui copied to clipboard
dotnet
Blazor Hybrid is not supported on Macs running MacOS 11.
Description
Same exact issue as here: https://github.com/dotnet/maui/issues/18419 However, I cannot update the machine that's looking to run the app. It's on MacOS 11.7.10 and cannot be updated further. Is there any way to build a Blazor Hybrid app that will run on this MBP?
Steps to Reproduce
No response
Link to public reproduction project repository
No response
Version with bug
8.0.3
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
MacOS 11.7.10
Did you find any workaround?
No response
Relevant log output
No response
It could be that as I mentioned in https://github.com/dotnet/maui/issues/18419#issuecomment-1788185256, the numbers for the supported version could be wrong?
That flag is set up specifically to only run on Mac Catalyst versions 13.3 and above, but I think that I could have confused the numbers. In short, the versions of Catalyst are tied to iOS versions, which then map to macOS versions. That flag was introduced on very recent MacOS version, so it probably is the case that the version number used here is wrong, and probably should be higher (maybe 16.x), which I think links to macOS 13.0+.
It should be a simple fix, but I don't have the gear to check those versions and verify if it would actually work with it, nor the time to get said gear to check, and it should probably be owned by someone on the MAUI team. @Eilon it could be a good first issue for someone new on the team (or collaborating) to check.
Whenever this issue gets fixed, it should. That's up for the MAUI team to figure out how they wanna schedule it. I am not on the team, I'm just helping with issues when I have time and I have other obligations to Visual Studio, and I rather someone on the team handle it at this point.
How do I get their attention? I haven't seen any reply from anyone on the Maui team regarding this. The documentation shows that Maui Blazor should not only be able to RUN on MacOS 11 and higher, but also be BUILT on MacOS 11 and higher. This is a show-stopping issue.
Awesome! Sorry for the newbie question, but how do I compile with this fixed version of Maui?
@MeestorX I filed https://github.com/dotnet/maui/issues/20451 to ensure we port this to a .NET 8 patch update. I think that this issue only affects the ability to use the Browser Developer Tools, so if you just leave that off on MacCatalyst, the app will work fine - but of course you won't have the Dev Tools available.
How can I test this?
In your app's MauiProgram.cs comment out the line that calls AddBlazorWebViewDeveloperTools() for a quick test. I think if you do that then the affected code won't even run.
If that works and you want to disable this code for just Mac scenarios, you could change MauiProgram.cs to look more like this:
#if DEBUG
#if !MACCATALYST
builder.Services.AddBlazorWebViewDeveloperTools();
#endif
builder.Logging.AddDebug();
#endif
And that way in Debug builds on all platforms except MacCatalyst you'll get the dev tools.
Thank you. I believe the problem occurs with release builds as well which already don't use the Developer Tools.
@MeestorX were you able to try it? It could be that the error always happens in which case a patch will be required.
Yes, just checked. A release build made on Sonoma (14.3) will not run on Big Sur (11.7). Same error as reported previously.
NSUnknownKeyException, reason: [<WKWebView 0x7fad54501a00> setValue:forUndefinedKey:]
Additionally, I cannot build on Big Sur due to the Xcode version requirements.
Is there a fix for this?
@MeestorX I think I found a way you can patch affected apps. Check out this repo where I tried it out: https://github.com/Eilon/maui19613MacCatWorkaround
The steps are:
- Copy this file to your project: https://github.com/Eilon/maui19613MacCatWorkaround/blob/main/maui19613MacCatWorkaround/Platforms/MacCatalyst/CustomBlazorWebViewHandler.cs
- Make sure it's in a similar path in the project (has to be in
Platforms/MacCatalyst/) - Update the namespace in the file as desired
- In your app's
MauiProgram.csadd this code: https://github.com/Eilon/maui19613MacCatWorkaround/blob/main/maui19613MacCatWorkaround/MauiProgram.cs#L18-L24 - (And update namespaces as needed)
Note that one limitation is that this class can't auto-detect whether you want Developer Tools enabled, so to switch that setting for MacCatalyst you'll need to edit this line: https://github.com/Eilon/maui19613MacCatWorkaround/blob/main/maui19613MacCatWorkaround/Platforms/MacCatalyst/CustomBlazorWebViewHandler.cs#L23 (or have it do something else smarter).
I tried this out on my Mac and it worked, but my Mac is running a later macOS so I can't test the exact case you have.
If you (or anyone else) can try it out, please let me know if it works!
Sadly, no. I just cloned your repository and did a dotnet run -f:net8.0-maccatalyst to check that it would run. Ran fine.
Did a dotnet publish -f:net8.0-maccatalyst and it created a .pkg file. Used that .pkg to install the program on another Sonoma machine. Installed and ran properly.
Used the same .pkg to install the program on a Big Sur machine, and no joy. Different error though.
The error this time is:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIWindowScene keyWindow]: unrecognized selector sent to instance 0x7ff737d5e6c0'
@MeestorX thank you for trying out the workaround. In CustomBlazorWebViewHandler can you try setting DeveloperToolsEnabled to false and see if that works?
Also this issue is closed because the work to fix the bug was completed, though the fix is not yet released. As such, there is no further action to take on the core issue (aside from me trying to come up with a temporary workaround).
That does not fix the issue. Same error.
Hmm that's a bit surprising to me. As far as I could tell, that error comes from code that with my fix shouldn't even run. Perhaps I missed something and that code isn't even running? Are you able to set a breakpoint anywhere in the new code (like on this line) and see if it gets hit, so that we know it's actually running?
That does not fix the issue. Same error.
Hmm that's a bit surprising to me. As far as I could tell, that error comes from code that with my fix shouldn't even run. Perhaps I missed something and that code isn't even running? Are you able to set a breakpoint anywhere in the new code (like on this line) and see if it gets hit, so that we know it's actually running?
Well, it does hit it in the debugger, but the debugger is on my Sonoma machine. I have to test actual builds on the Big Sur machine. Remember that I still cannot debug on my Big Sur machine because of the XCode requirements (which is another annoyance, as the dotnet docs say I SHOULD be able to build on MacOS 11 (Big Sur), but let's solve one thing at a time)
So, to be clear, I build on Sonoma, I'm packaging and running on Big Sur.
Yes that should be fine. The code in this case at compile time only cares about what platform is being targeted (for example, MACCATALYST) and not the specific OS version. So if the debugger showed the code is running on one Mac machine then it should be running on all machines running the same code.
I wonder if there's a way to see what .NET code is running when the error happens? From the logs seen in other issues, that stack doesn't seem to show the .NET call stack. Is it possible it's due to NativeAOT? And maybe if the code is run without NativeAOT we can see the .NET call stack and try to understand why the 'bad' code is running when it shouldn't even be called?
Yes that should be fine. The code in this case at compile time only cares about what platform is being targeted (for example,
MACCATALYST) and not the specific OS version. So if the debugger showed the code is running on one Mac machine then it should be running on all machines running the same code.
Copy. You copy that the error message is different with your code, right, in that it's choking on a different call?
I wonder if there's a way to see what .NET code is running when the error happens? From the logs seen in other issues, that stack doesn't seem to show the .NET call stack. Is it possible it's due to NativeAOT? And maybe if the code is run without NativeAOT we can see the .NET call stack and try to understand why the 'bad' code is running when it shouldn't even be called?
I assume you're not asking me! Lol I have no idea, but damn, would that ever be helpful to have some logs!
Oh I think I totally missed that the initial reports were about:
NSUnknownKeyException, reason: [<WKWebView 0x7fad54501a00> setValue:forUndefinedKey:]
But with the 'workaround' you're now seeing:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIWindowScene keyWindow]: unrecognized selector sent to instance 0x7ff737d5e6c0'
I'll have to think about that some more...
Unfortunately without a Mac with the older OS it's a bit hard for me to debug as well 😁
have to think about that some more...
Unfortunately without a Mac with the older OS it's a bit hard for me to debug as well 😁
Which is where logs would be helpful, I'm sure. Would there be something in the MacOS error screen or logs that I can send you?
Just tested with 8.0.201 and still the same error with the Maui Template and the workaround app you created. Is there even anyone that knows if a Maui Hybrid app can run on MacOS 11.x?