10 ms·

.NET 10 Preview 6 brings JIT improvements, one-shot tool execution

183 points by breve 1y ago

mattgreenrocks 1y ago
All I want is for dotnet watch to behave in a predictable way. In .NET 9, even when using —no-hot-reload, sometimes CSS changes to components are not picked up on Blazor components. It’s so aggravating because ASP.NET with server side Blazor components really has it all: type safety, server-side components ala Astro, fantastic ORM model, great runtime perf. But this little issue makes dev quite tedious at present: did I mistype a Tailwind class name, or did dotnet watch miss the change?
- whoknowsidont 1y ago
  [flagged]
  - zbentley 1y ago
    Say more?
    - PathOfEclipse 1y ago
      .NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM. Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper. Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.
      - pjmlp 1y ago
        And it does, how I wish for Valhala to become a reality, and finally having structs, spans, and all the other C++ like capabilities C# enjoys, and Java lacks.
      - Capricorn2481 1y ago
        > On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things). It seems like C# is within bounds of Java while also having great performance escape hatches.
    - whoknowsidont 1y ago
      Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around. Blazor's architectural model makes it impossible to be "performant." It's not even debatable. What you gain in DevEx you lose substantially in user experience.
      - mattgreenrocks 1y ago
        I'm speaking of static server-side components, thus no JS or WASM. Wouldn't touch any other Blazor mode for a public facing app.
        whoknowsidont 1y ago
        What do you gain from implementing in Blazor at that point?
      - zbentley 1y ago
        > Why do I have to provide it? The burden is the other way around. Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race. Let’s try this again: > Blazor's architectural model makes it impossible to be "performant." Say more?
        whoknowsidont 1y ago
        It sounds like you're just baiting.
- bob1029 1y ago
  > It’s so aggravating because ASP.NET with server side Blazor components really has it all Agreed. I bailed on Blazor over the tooling experience. Editing components in VS2022 was so janky for me. Syntax highlighting and intellisense never worked correctly.
  - jabart 1y ago
    We have had great success with Maui Blazor Hybrid. Each release hot reload gets better with fewer edge cases. I also found that having a separate .cs file instead of in one file helps with highlighing and intellisense.
  - MortyWaves 1y ago
    I don’t think there’s ever been any good tooling for the entire collection of ASP.NET DSLs. Be that MVC, Razor, or Blazor. Genuinely the same problems I had in VS2010 still happen in VS2022. There’s been some changes and improvements, but I really have to ask what the editor tooling team within that team are doing. I know there are some very difficult problems involved in parsing and formatting and highlighting bastardised mixtures of HTML, C#, and JavaScript all in the same file but if anything I think that perhaps suggests it was a bad idea to begin with. Consider the tooling for desktop and mobile apps with XAML (WPF, Avalonia) or even WinForms - they all have code behind support. Meaning there is no need (or ability) to mix all three in the same file.
- shortrounddev2 1y ago
  Are you using Visual Studio or another tool (vscode, vim, rider)? I found hot reload works a lot better in Visual Studio than any other IDE
  - deburo 1y ago
    That's true, but even in Visual Studio, Hot Reload breaks too often to be comfortable. It seems the intermediate .g.cs handling is a bit error prone.
  - mattgreenrocks 1y ago
    Rider, but I'm on Mac, so I can't use the real VS. I run dotnet watch from a terminal separately.
- rafaelmn 1y ago
  I inherited an MVC app that has a bunch of jQuery rendering crap and I would like to move to server side components - since you seem to be into Blazor Server side - have you heard of HTMX ? What would you say would be the benefit of Blazor vs HTMX and Razor Pages for subviews ? My experience with Microsoft UI toolkits after winforms, is that they are all janky over-engineered stuff (Silverlight/WPF/Xamarin/Maui) terrible tooling and support compared to alternatives. And Blazor using websockets makes me believe it is the same. The compile to WASM idea is a typical example of this. So what would be the selling point of Blazor ? It feels like you are just bundling stuff into Blazor magic when you could KISS with something simple like HTMX ?
  - doomroot13 1y ago
    As of today (and going forward), there are two different flavors of Blazor server-side rendering. There is the original version where the component is rendered on the server and interactivity is provided via websockets. Now there is also static server-side rendering, which works very similarly to razor pages, pages/components are rendered on the server and there is no interactivity. You can then, of course, add interactivity wherever you'd need it with server-interactive or webassembly interactive sub-components. I wouldn't necessarily say there's any benefit of Blazor over HTMX, it just depends on what you're most comfortable with and what works for you in your project. But you could architect your front-end in a similar way where you have small blazor components in your pages with interactivity. I think Blazor is in a nice state now, where I can iterate very quickly on projects with just static server side rendering and add interactivity whenever it's needed. It gives me a very fast website, rendered on the server, and the option to add some interactivity whenever I need.
  - WorldMaker 1y ago
    I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions. Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what if Angular/React was just Razor Pages running on the browser?" It's absolutely the opposite of KISS, it's lifting and shifting the entire .NET runtime in WASM to the client. Outside of corporate networks and packaged apps like Electron or Tauri, I'm not sure it makes any sense. But if you like writing Razor Pages and wished they ran closer to the client metal, and you can afford the bandwidth of an entire .NET application soup-to-nuts as your SPA framework, there is a sense to it. If all you think you need is Razor Pages with HTMX that's probably all you need.
- edtech_dev 1y ago
  I hear a lot of complaints about dotnet watch, but my experience doesn't match. I just use it from the terminal (instead of running it from an IDE) and it mostly just works.
tekdude 1y ago
Might be worth viewing the full list of changes in the blog post that the article links to: https://devblogs.microsoft.com/dotnet/dotnet-10-preview-6/ https://devblogs.microsoft.com/dotnet/dotnet-10-preview-6/
- Metalnem 1y ago
  Also, if you want to see the full list of changes in .NET 10 (not just the latest preview), you can find it here: https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/overview https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotn...
tester756 1y ago
.NET was the most sane programming ecosystem that I worked in. Great CLI, great package manager, very good stdlib, strong IDEs/Debuggers, etc. but sadly interesting jobs like OSes, databases and compilers are way less common than in C++ world :(
- reactordev 1y ago
  I agree. The stability comes from its ecosystem though. Enterprise Software. Where things like meticulous use of Omit and Task are common place and really REALLY bad things happen if you fuck up. But besides that, there’s a healthy gamedev community that embraced C# early and have been using it ever since. There’s C++ MFC guys that got duped into WPF and have been supporting it ever since. Winforms devs that are still trying to make a dark mode. I’ve even seen community grass roots “I need this in Silverlight” projects take hold and become one of the largest SDKs in the world. It’s cool. It’s fun. And with AOT, it’s everywhere. C# is like that cool uncle of your Father (Java) that likes to party all night but still holds a job. Maybe someday TS.Net will exist and we’ll all be singing “Back in my day”
  - pjmlp 1y ago
    I very much doubt about TS.Net, given the rewrite in Go decision. .NET nowadays has a serious adoption problem, and they should spend more time talking with their own colleagues at Azure, about their use of Java, Go, Rust.
    - reactordev 1y ago
      I know, so sad, could have been a great opportunity.
      - pjmlp 1y ago
        Just like every CNCF project that Azure contributes to, written in Go or Rust, which could have been great carrots to further .NET's adoption.
    - 1y ago
Alifatisk 1y ago
One-shot execution looks exciting, what problems does it solve? Less cluttering in the environment?
- pjerem 1y ago
  Scripting, CLI tools ...
  - chusk3 1y ago
    It also solves a more subtle problem - when people install a tool globally they install latest _at that time_. But the world doesn't stand still, and things get updated. `dnx` always uses the latest available version by default (you can of course pin with `dnx <package>@<version>`) so that you never get out of date.
croes 1y ago
I prefer .Net Framework 4.8 Longer lifetime than any .Net version.
- brokencode 1y ago
  Is upgrading every 3 years really that bad? As far as I know, they typically aren’t removing features or causing disruptive changes in .NET versions. They did when switching away from .NET Framework, but this was because they had to reimplement many features from scratch to work on other platforms, and certain parts got left behind.
  - croes 1y ago
    With all the dependencies that maybe getting an update to the new .Net version, yes.
  - ewoodrich 1y ago
    The last few .NET updates have been pretty much effortless updates for us. These are internal web apps and not using really esoteric C# features but that probably describes a reasonably large percentage of enterprise .NET adoption.
    - nartho 1y ago
      I don't think they introduced any breaking changes after .NET 6
      - Salgat 1y ago
        The only breaking change for us was how .NET 7 introduced [FromServices] which causes controller methods to use dependency injection for attributeless parameters. Confused me at first since it was a rather subtle update that didn't break anything until runtime.
      - orphea 1y ago
        Every version had breaking changes, they could not affect you too much though: https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0 https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
giancarlostoro 1y ago
Only thing I want to hear about lately is the next major version of Visual Studio, I feel like it will never come. I always feel like every major version has drastic improvements, and I'm starved for them.
- qingcharles 1y ago
  This thing has barely changed in the ~30 years I've been using it. There's definitely room for some more improvements.
  - sumtechguy 1y ago
    You can divide visual studio into 4 era's. The vs6 (we smashed all of our dev tooling together and its integrated decently) era, the vs2002/vs2003/vs2005 (we broke it all and you will like it and never speak of C++ again), vs2010 era (we fixed all of that from 2002 sorry about that), vs2017/vs2022 (it updates from the internet and takes forever to install and now does everything). The problem is MS is unwilling to stick with anything dev wise. The whole ecos system is a littered realm of half forgotten techs that may or may not be supported anymore. Wrapped with very confusing messaging to the devs what to use.
    - tracker1 1y ago
      I prefer VS Code... though MS has for better or worse kept the .Net tooling relatively weak. I'll use Rider or VS on a few occasions... then retreat back to Code as much as I can. For split web projects, definitely work on the web ui in VS Code.
      - giancarlostoro 1y ago
        I used to like VS Code, but something about it changed and it does not feel as snappy as it once did for me. Now I prefer Zed.
        pjmlp 1y ago
jug 1y ago
My favorite .NET 10 feature so far is not within the .NET library itself, but `dotnet tool exec` to run C# files as scripts without a build step. This has been available in F# for a long time via `dotnet fsi`, and for C# also via the third party cs-script tool. It took a surprisingly long time to officially reach the primary .NET language! I only really wish C# would’ve been directly integrated as an alternative scripting language in PowerShell. You may balk at the idea for causing a ton of cruft for people who don’t need it; ”a whole new scripting language!” But the thing is — PowerShell already builds upon .NET so supporting a new language is a rather small effort (relatively speaking) if it happens to be a .NET language. And C# just feels so much better for me to code in when the scripts grow in size. I’m not sure I’ll ever become friends with the implicit returns. C# has become particularly suitable for scripting with the recent developments in the language: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/program-structure/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
- munchler 1y ago
  One of many examples of C# following in F#'s footprints years later. F# deserves a higher profile in the .NET ecosystem.
  - eyegor 1y ago
    F# has been a third class citizen for a long time... Last I heard the entire f# team was ~10 people. Pretty sure "find references" still doesn't work across c# and f# (if you call a c# method from f# or vise versa). That also means symbol renames don't work correctly.
    - nickpeterson 1y ago
      I agree, but somewhat paradoxically, F#’s lack of new features kind of becomes a feature. Have you seen the number of C# features added in the last 5-10 years? It’s crazy
      - pshirshov 1y ago
sergiotapia 1y ago
I haven't used C#/.NET since .NET 4 - I remember it was great, yet heavily tied into Visual Studio, and forget about using CLI for things like most other languages. It was all GUI or nothing. Insurmountable XML files. How are things these days with .NET 10! Jesus, 10! Dudes who use it daily, what is your favorite feature you think?
- osigurdson 1y ago
  The version numbers used to increase much more slowly. Since the .NET (modernized / cross platform) core "track" the version number increments every year.
  - WorldMaker 1y ago
    The version increments roughly every 6 months. It's almost the exact same update cadence as NodeJS: LTS versions are even numbers released in the Fall and STS versions are odd numbers released in the Spring. STS often focuses on "bleeding edge features" and LTS often on performance and stability. (Though both are year round projects and there are bleeding edge features in an LTS and perf/stability fixes in an STS.)
    - rawling 1y ago
      https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-and-net-core https://learn.microsoft.com/en-us/lifecycle/products/microso... The last 5 version have been released a year apart, in Novembers.
- majora2007 1y ago
  Very different. That was the .NET I knew in college, .NET Core really changed the game. I personally use CLI just for EF Core (ORM) but Rider support is there so you're not tied to VS. My fav feature is honestly how little boilerplate I need compared to Spring Boot and the syntax sugar is honestly really nice.
- oneplane 1y ago
  It's still stuck in weird formats and monoliths. A lot of GUI-only stuff has been ported to the mega CLI, but it's still the weird Visual Studio format plus XML files that you cannot replace with a simple Makefile. You still can't just compile a bit of C# as-is, it must have the Solution, Project, Assembly etc. chain, the run-as-script feature is nice (lots of cheers when that was presented! even on the live stream), but it's specifically not designed to allow you to assemble a toolchain that works for what you need. There is only one and it has everything, no options. The question, of course, becomes: when does that matter? For a lot of people who are in to .NET, they see that as a benefit. Look at Go through this lens, and it's similar; the go CLI is the compiler, linker, package manager etc. I suppose the biggest difference is that it doesn't prescribe solutions and projects and file formats to go with them, which enables you to put this in any existing CI, make or other system.
devwastaken 1y ago
reminder the .net compiler is IP of microsoft and they state this clearly when you invoke it on any platform other than windows. you are merging your company with microsoft and windows if you use it.
- zaphar 1y ago
  It is fully open source so... who cares?
  - devwastaken 1y ago
    not the compiler and toolchain
    - zaphar 1y ago
      Yes it is. you can fork the roslyn compiler and toolchain here: https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn It's even an mit license one of the most permissive.
      - devwastaken 1y ago
        When you attempt to use .net toolchain on mac or anywhere else you are met with a clear disclaimer that it is microsoft IP. doesnt matter what license roslyn has
- dimaaan 1y ago
  MIT license: https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn
- jcotton42 1y ago
  > you are merging your company with microsoft and windows if you use it That's not how that works. Nothing about the .NET license entitles Microsoft to what you make with the tooling.
brainzap 1y ago
They should fix github issues and write in-depth tutorials, instead of AI features or minimal API.
- stronglikedan 1y ago
  "they" are more than one person and can do more than one thing at a time
- junto 1y ago
  I adore minimal API and when paired with Carter it’s just gorgeous. https://github.com/CarterCommunity/Carter https://github.com/CarterCommunity/Carter My current absolute favorite is .NET Aspire. Build distributed applications with an OTEL support dashboard - up and running in minutes. https://learn.microsoft.com/en-gb/dotnet/aspire/whats-new/dotnet-aspire-9.4 https://learn.microsoft.com/en-gb/dotnet/aspire/whats-new/do... Only gap in Aspire is deployment (k8s) tooling which is on the way.
smackeyacky 1y ago
All these changes, yet still no satisfactory UI framework. Still no migration path from WinForms to something modern. I love .NET but if you're taking on an older desktop app that is still using VB.NET and WinForms it feels like Microsoft have decided to let you circle the drain with no supported way forward into MAUI or whatever stupid XAML UI they decided is the solution these days. On a server, .NET is fantastic and it's entirely possible to build and debug your system on Linux with no loss of productivity, but the desktop stuff is bad and getting worse.
- cheschire 1y ago
  I've tried each iteration of UI paradigm they've tried since WinRT and never really had any significant problems with any of them. WinRT, UWP, WinUI, MAUI... But then they aren't even willing to invest the time to dogfood their own products and fully replace the windows UI. Really doesn't inspire confidence. I suspect they also made a bad bet by going so hard on blazor without putting more support behind WASM itself. Now that's stalled out with WASM's own failure to reach critical mass.
  - brokencode 1y ago
    Microsoft has zero vision in the UI space. It’s crazy that there isn’t there a single, obvious solution for developing Windows applications in 2025. I agree that it seems they’ve made some bad bets and now are bogged down supporting half a dozen different frameworks with different limitations and tradeoffs. They keep trying to reinvent the wheel, but it doesn’t seem like they’ve ever really meaningfully improved on WPF. At least there is Avalonia for an open source, cross platform WPF alternative. It seems like the sanest way of making desktop applications with C# currently.
  - pjmlp 1y ago
    That would be a first, not having significant problems. As someone that was deeply invested into WinRT since Windows 8, and went back into distributed systems and Web after all the disappointment regarding how managemetn handled it. Everyone on the Windows development ecosystem has had enough from the multiple reboots and tool changes, UWP never being as good as WPF, WinUI iterations even worse, the team now went radio silent, the last community call was a disaster,...
sharken 1y ago
Looking forward to playing with 'dotnet run app.cs' instead of PowerShell. It'll probably not be really useful until multiple files support arrives in .NET 11: https://github.com/dotnet/sdk/issues/48174 https://github.com/dotnet/sdk/issues/48174

183 points by breve 1y ago

All I want is for dotnet watch to behave in a predictable way. In .NET 9, even when using —no-hot-reload, sometimes CSS changes to components are not picked up on Blazor components. It’s so aggravating because ASP.NET with server side Blazor components really has it all: type safety, server-side components ala Astro, fantastic ORM model, great runtime perf. But this little issue makes dev quite tedious at present: did I mistype a Tailwind class name, or did dotnet watch miss the change?

whoknowsidont 1y ago
[flagged]
- zbentley 1y ago
  Say more?
  - PathOfEclipse 1y ago
    .NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM. Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper. Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.
    - pjmlp 1y ago
      And it does, how I wish for Valhala to become a reality, and finally having structs, spans, and all the other C++ like capabilities C# enjoys, and Java lacks.
    - Capricorn2481 1y ago
      > On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things). It seems like C# is within bounds of Java while also having great performance escape hatches.
  - whoknowsidont 1y ago
    Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around. Blazor's architectural model makes it impossible to be "performant." It's not even debatable. What you gain in DevEx you lose substantially in user experience.
    - mattgreenrocks 1y ago
      I'm speaking of static server-side components, thus no JS or WASM. Wouldn't touch any other Blazor mode for a public facing app.
      - whoknowsidont 1y ago
        What do you gain from implementing in Blazor at that point?
    - zbentley 1y ago
      > Why do I have to provide it? The burden is the other way around. Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race. Let’s try this again: > Blazor's architectural model makes it impossible to be "performant." Say more?
      - whoknowsidont 1y ago
        It sounds like you're just baiting.
bob1029 1y ago
> It’s so aggravating because ASP.NET with server side Blazor components really has it all Agreed. I bailed on Blazor over the tooling experience. Editing components in VS2022 was so janky for me. Syntax highlighting and intellisense never worked correctly.
- jabart 1y ago
  We have had great success with Maui Blazor Hybrid. Each release hot reload gets better with fewer edge cases. I also found that having a separate .cs file instead of in one file helps with highlighing and intellisense.
- MortyWaves 1y ago
  I don’t think there’s ever been any good tooling for the entire collection of ASP.NET DSLs. Be that MVC, Razor, or Blazor. Genuinely the same problems I had in VS2010 still happen in VS2022. There’s been some changes and improvements, but I really have to ask what the editor tooling team within that team are doing. I know there are some very difficult problems involved in parsing and formatting and highlighting bastardised mixtures of HTML, C#, and JavaScript all in the same file but if anything I think that perhaps suggests it was a bad idea to begin with. Consider the tooling for desktop and mobile apps with XAML (WPF, Avalonia) or even WinForms - they all have code behind support. Meaning there is no need (or ability) to mix all three in the same file.
shortrounddev2 1y ago
Are you using Visual Studio or another tool (vscode, vim, rider)? I found hot reload works a lot better in Visual Studio than any other IDE
- deburo 1y ago
  That's true, but even in Visual Studio, Hot Reload breaks too often to be comfortable. It seems the intermediate .g.cs handling is a bit error prone.
- mattgreenrocks 1y ago
  Rider, but I'm on Mac, so I can't use the real VS. I run dotnet watch from a terminal separately.
rafaelmn 1y ago
I inherited an MVC app that has a bunch of jQuery rendering crap and I would like to move to server side components - since you seem to be into Blazor Server side - have you heard of HTMX ? What would you say would be the benefit of Blazor vs HTMX and Razor Pages for subviews ? My experience with Microsoft UI toolkits after winforms, is that they are all janky over-engineered stuff (Silverlight/WPF/Xamarin/Maui) terrible tooling and support compared to alternatives. And Blazor using websockets makes me believe it is the same. The compile to WASM idea is a typical example of this. So what would be the selling point of Blazor ? It feels like you are just bundling stuff into Blazor magic when you could KISS with something simple like HTMX ?
- doomroot13 1y ago
  As of today (and going forward), there are two different flavors of Blazor server-side rendering. There is the original version where the component is rendered on the server and interactivity is provided via websockets. Now there is also static server-side rendering, which works very similarly to razor pages, pages/components are rendered on the server and there is no interactivity. You can then, of course, add interactivity wherever you'd need it with server-interactive or webassembly interactive sub-components. I wouldn't necessarily say there's any benefit of Blazor over HTMX, it just depends on what you're most comfortable with and what works for you in your project. But you could architect your front-end in a similar way where you have small blazor components in your pages with interactivity. I think Blazor is in a nice state now, where I can iterate very quickly on projects with just static server side rendering and add interactivity whenever it's needed. It gives me a very fast website, rendered on the server, and the option to add some interactivity whenever I need.
- WorldMaker 1y ago
  I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions. Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what if Angular/React was just Razor Pages running on the browser?" It's absolutely the opposite of KISS, it's lifting and shifting the entire .NET runtime in WASM to the client. Outside of corporate networks and packaged apps like Electron or Tauri, I'm not sure it makes any sense. But if you like writing Razor Pages and wished they ran closer to the client metal, and you can afford the bandwidth of an entire .NET application soup-to-nuts as your SPA framework, there is a sense to it. If all you think you need is Razor Pages with HTMX that's probably all you need.
edtech_dev 1y ago
I hear a lot of complaints about dotnet watch, but my experience doesn't match. I just use it from the terminal (instead of running it from an IDE) and it mostly just works.

tekdude 1y ago

Might be worth viewing the full list of changes in the blog post that the article links to: https://devblogs.microsoft.com/dotnet/dotnet-10-preview-6/ https://devblogs.microsoft.com/dotnet/dotnet-10-preview-6/

Metalnem 1y ago
Also, if you want to see the full list of changes in .NET 10 (not just the latest preview), you can find it here: https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/overview https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotn...

tester756 1y ago

.NET was the most sane programming ecosystem that I worked in. Great CLI, great package manager, very good stdlib, strong IDEs/Debuggers, etc. but sadly interesting jobs like OSes, databases and compilers are way less common than in C++ world :(

reactordev 1y ago
I agree. The stability comes from its ecosystem though. Enterprise Software. Where things like meticulous use of Omit and Task are common place and really REALLY bad things happen if you fuck up. But besides that, there’s a healthy gamedev community that embraced C# early and have been using it ever since. There’s C++ MFC guys that got duped into WPF and have been supporting it ever since. Winforms devs that are still trying to make a dark mode. I’ve even seen community grass roots “I need this in Silverlight” projects take hold and become one of the largest SDKs in the world. It’s cool. It’s fun. And with AOT, it’s everywhere. C# is like that cool uncle of your Father (Java) that likes to party all night but still holds a job. Maybe someday TS.Net will exist and we’ll all be singing “Back in my day”
- pjmlp 1y ago
  I very much doubt about TS.Net, given the rewrite in Go decision. .NET nowadays has a serious adoption problem, and they should spend more time talking with their own colleagues at Azure, about their use of Java, Go, Rust.
  - reactordev 1y ago
    I know, so sad, could have been a great opportunity.
    - pjmlp 1y ago
      Just like every CNCF project that Azure contributes to, written in Go or Rust, which could have been great carrots to further .NET's adoption.
  - 1y ago

Alifatisk 1y ago

One-shot execution looks exciting, what problems does it solve? Less cluttering in the environment?

pjerem 1y ago
Scripting, CLI tools ...
- chusk3 1y ago
  It also solves a more subtle problem - when people install a tool globally they install latest _at that time_. But the world doesn't stand still, and things get updated. `dnx` always uses the latest available version by default (you can of course pin with `dnx <package>@<version>`) so that you never get out of date.

croes 1y ago

I prefer .Net Framework 4.8 Longer lifetime than any .Net version.

brokencode 1y ago
Is upgrading every 3 years really that bad? As far as I know, they typically aren’t removing features or causing disruptive changes in .NET versions. They did when switching away from .NET Framework, but this was because they had to reimplement many features from scratch to work on other platforms, and certain parts got left behind.
- croes 1y ago
  With all the dependencies that maybe getting an update to the new .Net version, yes.
- ewoodrich 1y ago
  The last few .NET updates have been pretty much effortless updates for us. These are internal web apps and not using really esoteric C# features but that probably describes a reasonably large percentage of enterprise .NET adoption.
  - nartho 1y ago
    I don't think they introduced any breaking changes after .NET 6
    - Salgat 1y ago
      The only breaking change for us was how .NET 7 introduced [FromServices] which causes controller methods to use dependency injection for attributeless parameters. Confused me at first since it was a rather subtle update that didn't break anything until runtime.
    - orphea 1y ago
      Every version had breaking changes, they could not affect you too much though: https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0 https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

giancarlostoro 1y ago

Only thing I want to hear about lately is the next major version of Visual Studio, I feel like it will never come. I always feel like every major version has drastic improvements, and I'm starved for them.

qingcharles 1y ago
This thing has barely changed in the ~30 years I've been using it. There's definitely room for some more improvements.
- sumtechguy 1y ago
  You can divide visual studio into 4 era's. The vs6 (we smashed all of our dev tooling together and its integrated decently) era, the vs2002/vs2003/vs2005 (we broke it all and you will like it and never speak of C++ again), vs2010 era (we fixed all of that from 2002 sorry about that), vs2017/vs2022 (it updates from the internet and takes forever to install and now does everything). The problem is MS is unwilling to stick with anything dev wise. The whole ecos system is a littered realm of half forgotten techs that may or may not be supported anymore. Wrapped with very confusing messaging to the devs what to use.
  - tracker1 1y ago
    I prefer VS Code... though MS has for better or worse kept the .Net tooling relatively weak. I'll use Rider or VS on a few occasions... then retreat back to Code as much as I can. For split web projects, definitely work on the web ui in VS Code.
    - giancarlostoro 1y ago
      I used to like VS Code, but something about it changed and it does not feel as snappy as it once did for me. Now I prefer Zed.
      - pjmlp 1y ago

jug 1y ago

My favorite .NET 10 feature so far is not within the .NET library itself, but `dotnet tool exec` to run C# files as scripts without a build step. This has been available in F# for a long time via `dotnet fsi`, and for C# also via the third party cs-script tool. It took a surprisingly long time to officially reach the primary .NET language! I only really wish C# would’ve been directly integrated as an alternative scripting language in PowerShell. You may balk at the idea for causing a ton of cruft for people who don’t need it; ”a whole new scripting language!” But the thing is — PowerShell already builds upon .NET so supporting a new language is a rather small effort (relatively speaking) if it happens to be a .NET language. And C# just feels so much better for me to code in when the scripts grow in size. I’m not sure I’ll ever become friends with the implicit returns. C# has become particularly suitable for scripting with the recent developments in the language: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/program-structure/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

munchler 1y ago
One of many examples of C# following in F#'s footprints years later. F# deserves a higher profile in the .NET ecosystem.
- eyegor 1y ago
  F# has been a third class citizen for a long time... Last I heard the entire f# team was ~10 people. Pretty sure "find references" still doesn't work across c# and f# (if you call a c# method from f# or vise versa). That also means symbol renames don't work correctly.
  - nickpeterson 1y ago
    I agree, but somewhat paradoxically, F#’s lack of new features kind of becomes a feature. Have you seen the number of C# features added in the last 5-10 years? It’s crazy
    - pshirshov 1y ago

sergiotapia 1y ago

I haven't used C#/.NET since .NET 4 - I remember it was great, yet heavily tied into Visual Studio, and forget about using CLI for things like most other languages. It was all GUI or nothing. Insurmountable XML files. How are things these days with .NET 10! Jesus, 10! Dudes who use it daily, what is your favorite feature you think?

osigurdson 1y ago
The version numbers used to increase much more slowly. Since the .NET (modernized / cross platform) core "track" the version number increments every year.
- WorldMaker 1y ago
  The version increments roughly every 6 months. It's almost the exact same update cadence as NodeJS: LTS versions are even numbers released in the Fall and STS versions are odd numbers released in the Spring. STS often focuses on "bleeding edge features" and LTS often on performance and stability. (Though both are year round projects and there are bleeding edge features in an LTS and perf/stability fixes in an STS.)
  - rawling 1y ago
    https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-and-net-core https://learn.microsoft.com/en-us/lifecycle/products/microso... The last 5 version have been released a year apart, in Novembers.
majora2007 1y ago
Very different. That was the .NET I knew in college, .NET Core really changed the game. I personally use CLI just for EF Core (ORM) but Rider support is there so you're not tied to VS. My fav feature is honestly how little boilerplate I need compared to Spring Boot and the syntax sugar is honestly really nice.
oneplane 1y ago
It's still stuck in weird formats and monoliths. A lot of GUI-only stuff has been ported to the mega CLI, but it's still the weird Visual Studio format plus XML files that you cannot replace with a simple Makefile. You still can't just compile a bit of C# as-is, it must have the Solution, Project, Assembly etc. chain, the run-as-script feature is nice (lots of cheers when that was presented! even on the live stream), but it's specifically not designed to allow you to assemble a toolchain that works for what you need. There is only one and it has everything, no options. The question, of course, becomes: when does that matter? For a lot of people who are in to .NET, they see that as a benefit. Look at Go through this lens, and it's similar; the go CLI is the compiler, linker, package manager etc. I suppose the biggest difference is that it doesn't prescribe solutions and projects and file formats to go with them, which enables you to put this in any existing CI, make or other system.

devwastaken 1y ago

reminder the .net compiler is IP of microsoft and they state this clearly when you invoke it on any platform other than windows. you are merging your company with microsoft and windows if you use it.

zaphar 1y ago
It is fully open source so... who cares?
- devwastaken 1y ago
  not the compiler and toolchain
  - zaphar 1y ago
    Yes it is. you can fork the roslyn compiler and toolchain here: https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn It's even an mit license one of the most permissive.
    - devwastaken 1y ago
      When you attempt to use .net toolchain on mac or anywhere else you are met with a clear disclaimer that it is microsoft IP. doesnt matter what license roslyn has
dimaaan 1y ago
MIT license: https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn
jcotton42 1y ago
> you are merging your company with microsoft and windows if you use it That's not how that works. Nothing about the .NET license entitles Microsoft to what you make with the tooling.

brainzap 1y ago

They should fix github issues and write in-depth tutorials, instead of AI features or minimal API.

stronglikedan 1y ago
"they" are more than one person and can do more than one thing at a time
junto 1y ago
I adore minimal API and when paired with Carter it’s just gorgeous. https://github.com/CarterCommunity/Carter https://github.com/CarterCommunity/Carter My current absolute favorite is .NET Aspire. Build distributed applications with an OTEL support dashboard - up and running in minutes. https://learn.microsoft.com/en-gb/dotnet/aspire/whats-new/dotnet-aspire-9.4 https://learn.microsoft.com/en-gb/dotnet/aspire/whats-new/do... Only gap in Aspire is deployment (k8s) tooling which is on the way.

smackeyacky 1y ago

All these changes, yet still no satisfactory UI framework. Still no migration path from WinForms to something modern. I love .NET but if you're taking on an older desktop app that is still using VB.NET and WinForms it feels like Microsoft have decided to let you circle the drain with no supported way forward into MAUI or whatever stupid XAML UI they decided is the solution these days. On a server, .NET is fantastic and it's entirely possible to build and debug your system on Linux with no loss of productivity, but the desktop stuff is bad and getting worse.

cheschire 1y ago
I've tried each iteration of UI paradigm they've tried since WinRT and never really had any significant problems with any of them. WinRT, UWP, WinUI, MAUI... But then they aren't even willing to invest the time to dogfood their own products and fully replace the windows UI. Really doesn't inspire confidence. I suspect they also made a bad bet by going so hard on blazor without putting more support behind WASM itself. Now that's stalled out with WASM's own failure to reach critical mass.
- brokencode 1y ago
  Microsoft has zero vision in the UI space. It’s crazy that there isn’t there a single, obvious solution for developing Windows applications in 2025. I agree that it seems they’ve made some bad bets and now are bogged down supporting half a dozen different frameworks with different limitations and tradeoffs. They keep trying to reinvent the wheel, but it doesn’t seem like they’ve ever really meaningfully improved on WPF. At least there is Avalonia for an open source, cross platform WPF alternative. It seems like the sanest way of making desktop applications with C# currently.
- pjmlp 1y ago
  That would be a first, not having significant problems. As someone that was deeply invested into WinRT since Windows 8, and went back into distributed systems and Web after all the disappointment regarding how managemetn handled it. Everyone on the Windows development ecosystem has had enough from the multiple reboots and tool changes, UWP never being as good as WPF, WinUI iterations even worse, the team now went radio silent, the last community call was a disaster,...

sharken 1y ago

Looking forward to playing with 'dotnet run app.cs' instead of PowerShell. It'll probably not be really useful until multiple files support arrives in .NET 11: https://github.com/dotnet/sdk/issues/48174 https://github.com/dotnet/sdk/issues/48174