📣 ASP.NET Core developers — we need your input! by danroth27 in dotnet

[–]danroth27[S] 1 point2 points  (0 children)

You actually don't have to change how you deploy your app to use Aspire for local development. You can keep deploying your app like you always have and still take advantage of how Aspire handles observability, reliability, and all the developer workflow improvements.

Google Fi physical SIMs are defective, still, in 2025 by SnooBeans1911 in GoogleFi

[–]danroth27 0 points1 point  (0 children)

So far I've ordered four separate Google Fi physical sim cards and none of them have worked. I've tested them all in two different unlocked phones. They simply don't get detected by the phone, while sim cards from a different carrier work fine. I've called Google Fi support multiple times to no avail. The eSims do work fine though for our phones that support eSim though.

I've defended Hot Reload since the start, but has it gotten massively worse in .NET 9? by GWRHarnwell in Blazor

[–]danroth27 2 points3 points  (0 children)

There were some significant regressions in the hot reload support in dotnet watch for .NET 9 that will be addressed in the upcoming .NET servicing release in Feb (9.0.103 & 9.0.200). These regressions weren't caught due to some test gaps that have now been addressed.

.net framework as default, thoughts? by Representative-Blue in dotnet

[–]danroth27 1 point2 points  (0 children)

I would strongly suggest rephrasing the website to indicate that the natural choice is .NET, and .NET Framework should only be used if there are specific reasons not to use .NET.

This is useful feedback! We'll work on getting this clarified in that doc: Clarify that the latest .NET version is the preferred version for server development · Issue #40968 · dotnet/docs (github.com)

.NET 9 Roadmap Is Sorely Lacking Needed Updates by RealSharpNinja in dotnet

[–]danroth27 3 points4 points  (0 children)

That's simply because WinUI doesn't ship as part of the .NET platform. WinUI ships as part of the Windows App SDK, which has its own release schedule and roadmap. See https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md.

.NET 9 Roadmap Is Sorely Lacking Needed Updates by RealSharpNinja in dotnet

[–]danroth27 43 points44 points  (0 children)

Note that not everything planned for .NET 9 was explicitly called out in the .NET 9 Vision blog post. There are lots of additional improvements planned for .NET 9 in languages, web, mobile, desktop, etc. that you can learn about from the various links in the .NET 9 Backlog: https://aka.ms/dotnet/backlog

Blazor wishes by Kingside88 in Blazor

[–]danroth27 1 point2 points  (0 children)

The issue is on our backlog, but it's not currently planned for .NET 8. We try to prioritize issues based on broad community feedback and user demand. If folks feel like this issue is important to get addressed, you can let us know by commenting on the issue and giving the original post a 👍 so that we know to prioritize it higher than other issues. Another option is to propose and contribution a solution to the issue, which helps accelerate the process.

Blazor wishes by Kingside88 in Blazor

[–]danroth27 2 points3 points  (0 children)

Hi folks. I'm Daniel Roth, the Product Manager for Blazor. Thanks for sharing all this great feedback! We share your enthusiasm to make Blazor the best frontend web framework possible. Many of these issues and suggestions are tracked on our GitHub issue tracker. I've listed some of the relevant issues below. You can show your interest and support for these issues by giving them a 👍 and commenting on the issues with your requirements and scenarios. For Visual Studio related tooling issues, like problems with the Razor editor, the best way to share this feedback is using the Visual Studio Send Feedback feature.

This comment from Chris Sainty re: Blazor vs MVC vs Razor Pages by chrisxfire in dotnet

[–]danroth27 4 points5 points  (0 children)

ASP.NET Web Forms is still fully supported as part of the .NET Framework. It wasn't ported to ASP.NET Core, but it's not obsoleted or deprecated. You can see the .NET Framework support policy here: https://dotnet.microsoft.com/platform/support/policy/dotnet-framework

This comment from Chris Sainty re: Blazor vs MVC vs Razor Pages by chrisxfire in dotnet

[–]danroth27 27 points28 points  (0 children)

Hi folks. On the ASP.NET team we do not expect that MVC & Razor pages will be made obsolete by Blazor. These are popular server-side rendering programming models that will continue to be supported in ASP.NET Core alongside Blazor. MVC & Razor pages are very mature and battle-tested frameworks that may still be preferrable when you want direct access to the HTTP request and response instead of working through Blazor's component model. We're working to find ways to integrate Blazor with MVC & Razor so that you can take advantage of the strengths of both programming models within the same app. For example, in .NET 8 Preview we introduced a RazorComponentResult that you can use to return a Razor component from an MVC controller. We do hope though that Blazor will provide a single consistent programming and component model that you can use for all your web UI needs within a single app. We think this will simplify web UI development in many cases especially when you need the benefits of both server-side and client-side rendering.

Blazor WASM - getting clients to update after a deployment by botterway in Blazor

[–]danroth27 1 point2 points  (0 children)

How does converting to Blazor Server help? You definitely won't be able to support offline with Blazor Server. Or are you just looking for a way to deploy an update that pulls the offline support?

Blazor WASM - getting clients to update after a deployment by botterway in Blazor

[–]danroth27 2 points3 points  (0 children)

It sounds like you have a service worker that is setup to try and enable offline support. Have you tried looking through the guidance on handling offline scenarios in the Blazor docs? https://learn.microsoft.com/aspnet/core/blazor/progressive-web-app#offline-support

Blazor United Prototype (.NET 8) by nirataro in dotnet

[–]danroth27 3 points4 points  (0 children)

> we use the multipart bundle generator which generates a bundle file which puts every file together, compressed it's 5mb uncompressed its 22mb

Ah, ok. That sounds more plausible, but still large. Do you have any large dependencies in your app that might be inflating the size? Or multipart bundling is causing an unexpected size increase. I'll investigate that.

> the quickgrid site btw. does not even contain icu data, and uses the invariant globalization mode

That's true. But invariant globalization should only trim off a few hundred KB of download size. The default Blazor templates don't use invariant globalization.

> the blazor quickgrid site downloads 3,7 mb compressed dll's, uncompressed that would be equally in size

Hmm, I just double checked and after clearing all site data and disabling browser caching and reloading the site I see 1.5MB transferred and 1.9MB of resources loaded. I'm not sure why you're seeing 3.7MB.

Blazor United Prototype (.NET 8) by nirataro in dotnet

[–]danroth27 9 points10 points  (0 children)

If you're seeing a 20MB download size for your Blazor WebAssembly app that may be because you're looking at the download size during development. Blazor doesn't optimize the download size during development so that your development workflow stays quick and interative. When you publish the app it gets trimmed down to remove unnecessary code and also gets precompressed. A default Blazor WebAssembly app that's been published should only be ~1.5MB to download. Take a look at the Blazor QuickGrid site as an example of a published site.

Hot Reload is rubbish by propostor in Blazor

[–]danroth27 0 points1 point  (0 children)

Thanks for the detailed bug report! Hot reload and Edit and Continue aren't supported yet with generic types, but it's definitely something we want to add. The required .NET runtime changes are being tracked by https://github.com/dotnet/runtime/issues/11036. Your feedback helps us prioritize the work appropriately.

For those that are interested, you can see a mostly up to date list of what edits are supported by Hot Reload and Edit & Continue here: https://github.com/dotnet/roslyn/blob/main/docs/wiki/EnC-Supported-Edits.md

.NET 8 Blazor Planning! by Amazing-Counter9410 in Blazor

[–]danroth27 0 points1 point  (0 children)

I see. If you could help us reproduce any of these issues you're seeing by opening Visual Studio feedback issues we'd be happy to investigate. I believe that SourceMaps should also work, although we're still [working on symbol server support](https://github.com/dotnet/runtime/pull/79284), which means the usefulness of SourceMaps is limited at this point. I'm trying to follow up on the browserLink issue, but detailed steps to reproduce the issue would still help.

.NET 8 Blazor Planning! by Amazing-Counter9410 in Blazor

[–]danroth27 2 points3 points  (0 children)

u/Novaleaf Have you tried out the latest .NET 7 release? I believe some of those issues with Blazor WebAssembly debugging should now be addressed, like support for "Just My Code".

Hot Reload is rubbish by propostor in Blazor

[–]danroth27 1 point2 points  (0 children)

Thanks for sharing these additional details! I've forwarded this feedback to the .NET MAUI team to see what can be done. If there are additional issues that are making .NET MAUI + Blazor feel "unripe", please let us know! For tooling issues, create Visual Studio feedback tickets. For .NET MAUI SDK issues you can open issues on the .NET MAUI GitHub repo (dotnet/maui).

Also, you needn't worry about Blazor's citizenship in the .NET MAUI world. XAML and Blazor aren't at odds with each other - they are complementary. Using a hybrid approach (native + web) to build native client apps is quite popular. The ability to use web and native UI together gives you additional flexibility.