-
Notifications
You must be signed in to change notification settings - Fork 4.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
[8.0] HybridGlobalization problem in Blazor WASM targeting .NET 8 and published with .NET 9 SDK #109951
Comments
Tagging subscribers to 'arch-wasm': @lewing |
Tagging subscribers to this area: @dotnet/area-system-globalization |
Got exactly same problem with a Blazor wasm application that is targeting .NET 8 |
@ilonatommy Can you please verify if there is some misalignment between between .NET 9 SDK and .NET 8 runtime pack / workload for hybrid globalization? We have other problem with satellite assemblies #109604, but this one looks different |
My issue (Closed now, as I learned it was not an issue with the Fluxor library, but with dotnet itself): mrpmorris/Fluxor#515 I ran into this exact issue. This is the second Blazor-breaking regression in two years, and both cost me a week of work. |
I can confirm the same issue on our side. This is currently causing issues during our deployment as the Microsoft-hosted agents are starting to be updated as well. Our workaround is to also the global.json file to specify the target sdk during the "dotnet publish" command execution. We had issues in getting the pipeline agent to read the file because it needs to be created within the working directory of the agent, which was outside our repository files. A proposed work-around would be this:
This task creates the global.json file with version 8.0.X in the current working directory of the agent. Any following tasks will now be able to use it. I used an inline powershell scripts because I couldn't figure out how the "custom" command syntax works in the DotNetCoreCLI@2 task. Related information: https://stackoverflow.com/questions/68896612/working-directory-parameter-of-dotnetcorecl-publish-step |
Why don't you just use UseDotNet (https://learn.microsoft.com/en-gb/azure/devops/pipelines/tasks/reference/use-dotnet-v2?view=azure-pipelines&viewFallbackFrom=azure-devops) at the beginning of your pipeline.
|
Sorry for the delay, I was away. I am looking into it, from some reason net8 trims the
where runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/GlobalizationMode.cs Line 19 in 1e6311a
When we disable trimming (not recommended), the published app works fine. I will try to find out about the details behind it as soon as I can. |
Hi, we have tried to publish our app disabling trimming from Blazor webassembly client project, unfortunatly with no success. In our case, the problem arises on rendering a chart component, which relies on HybridGlobalization (ScottPlot.NET). Thank you! |
@pragmaeuge, do I understand it correctly that in your case the project sets
You might be facing a different issue. Tell me more about it. |
@pragmaeuge, I used ScottPlot5 project from your repo to reproduce and I confirm that the change from #110183 helped. I cannot see
was a misunderstanding, maybe you meant "relies on System.Globalization library". In case my assumptions are incorrect or I checked a wrong project, let me know. Edit: interesting part of it is that adding
in the project I quoted, also removes the error. Now I would like to know where lies the difference between me using |
Hi, Thank you very much to have dig deeper in our issue, we have much appreciated it. |
Let me list a more detailed chain of events that made this issue surface only now.
|
Having the same issue with our blazor apps after upgrading VS 2022 to 17.12 |
@DaveVW-AWE, the backported PR should be in net8 with January release. For now, please consider discussed workaround of rolling back to sdk8 or, in case it's possible, updating the project to net9. |
Having some issues getting this workaround to work. We're not using DevOps, but have tried placing that particular global.json in our solution root, and individually in out Client/Server/Shared directories, but to no avail. Can someone share how to get the workaround to work when using Visual Studio and its standard Publish process? |
At the end and after a long time of frustration, the solucion was do upgrate to NET 9 |
Is there an existing issue for this?
Describe the bug
I have a Blazor WASM project that targeted .NET 8. After I installed the VS 2022 17.12 update, my app stopped working when published to a production server. The stack trace reported in the browser's Console window was:
Others have reported similar problems on StackOverflow here.
The VS 17.12 update removed the .NET 8.0.404 SDK and replaced it with the .NET 9.0.100 SDK. Something isn't working right with HybridGlobalization in that scenario.
I first worked around the problem by creating a global.json file and manually installing the .NET 8.0.404 SDK again (as suggested by Dimitris Maragkos). That commit can be seen here.
Later I worked around the problem by upgrading the project to target .NET 9 and publish with the .NET 9.0.100 SDK. That commit can be seen here.
The production problem only occurs when trying to target .NET 8 and publish with the .NET 9.0.100 SDK. That combination works in VS at build and debug time. It only fails when published. And my app does NOT opt-in with
<HybridGlobalization>true</HybridGlobalization>
as discussed here. I'm just usingStringComparer.CurrentCultureIgnoreCase
from a static initializer here.Expected Behavior
A Blazor WASM app that targets .NET 8 should be publilshable using the .NET 9 SDK without throwing
PlatformNotSupportedException: PlatformNotSupported_HybridGlobalization, HashCode
at runtime.Steps To Reproduce
No response
Exceptions (if any)
.NET Version
9.0.100
Anything else?
This started after installing the VS 2022 17.12 update, which removed the .NET 8.0.404 SDK. I had to manually reinstall that SDK to continue to target and publish .NET 8 versions that worked.
The text was updated successfully, but these errors were encountered: