[HN Gopher] .NET 10 Preview 6 brings JIT improvements, one-shot ...
___________________________________________________________________
.NET 10 Preview 6 brings JIT improvements, one-shot tool execution
Author : breve
Score : 145 points
Date : 2025-07-27 05:53 UTC (3 days ago)
(HTM) web link (www.infoworld.com)
(TXT) w3m dump (www.infoworld.com)
| mattgreenrocks wrote:
| 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?
| bob1029 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Rider, but I'm on Mac, so I can't use the real VS. I run
| dotnet watch from a terminal separately.
| rafaelmn wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rafaelmn wrote:
| >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.
|
| That is exactly my read of it, especially given Microsoft
| track record on delivering with stuff like this.
|
| Not sure about the Silverlight comparison - in the days of
| Flash, browsers did not even have a way to stream video
| reliably, nowadays it just cramming a square peg in to a
| round hole - heavyweight runtime built on multithreading
| crammed to a single threaded event loop. I have not tried
| it - but after using .net in much more powerful/native envs
| like Android - I know for a fact that the
| iteration/build/debugging story sucks compared to native
| JS/TS. Also as bad JS is, TS makes it saner, tooling has
| matured and DOM APIs are built for JS.
| WorldMaker wrote:
| > nowadays it just cramming a square peg in to a round
| hole - heavyweight runtime built on multithreading
| crammed to a single threaded event loop
|
| Sometimes the "event loop" part is forgotten because JS'
| single threaded thing is very "cooperatively threaded".
| This is a large part of why async/await works so well in
| JS and is growing so quickly in adoptions. .NET's
| multithreading is built in a way to excel in
| "cooperatively threaded" environments (its task pools are
| cooperative by default, for instance, and also arguably
| heavy use of async/await was C#'s idea first).
|
| It would be great to see more WASM multithreading powers,
| but writing C# for today's WASM environment doesn't feel
| that different from "regular" multi-threaded C#.
|
| > I know for a fact that the iteration/build/debugging
| story sucks compared to native JS/TS
|
| WASM debugging is nearly great, including growing
| Sourcemap support. The ability for Visual Studio to be
| the Debugger interface to Chromium-based browsers is more
| powerful that ever. Certainly in its debugging story
| Blazor WASM is much advanced from Silverlight which was
| only really debuggable in IE and then was still often
| flaky.
|
| > DOM APIs are built for JS
|
| There's still talk of making more direct DOM APIs for
| WASM. Might be interesting to see eventually.
|
| This is why it is so easy to relate Blazor WASM to React.
| Blazor is essentially using Razor templates to define a
| Virtual DOM which it then sends render updates across the
| WASM/JS boundary to a very tiny virtual DOM renderer.
|
| It's not what I'd use for smarter direct DOM work, but in
| comparison to React it gets the job done and works
| surprisingly well, even with the language barrier and
| data marshalling across sandbox layers.
|
| I've used Blazor WASM on Enterprise projects. I'd
| probably use it again on Enterprise projects. It can be
| real nice to have backend and frontend all entirely in
| C#. (In different projects. So that you can scale them
| independently if nothing else.)
| terandle wrote:
| Blazor static server side + HTMX is probably the only way to
| make a cost efficient and performant version of Blazor
| suitable for public websites. WASM is way too big and slow,
| Websockets take up server resources and cause problems with
| timeouts where the user has to refresh their screen losing
| all state.
| rafaelmn wrote:
| What would be the benefit over Razor pages tho ? Component
| model ? Feels like partial views and razor templates might
| not be the cleanest/dry-est solution but would make the
| implementation super straightforawd.
| tracker1 wrote:
| Jetbrains built some awesome tooling to support HTMX apps
| using razor engine and some MVC conventions. It's pretty
| neat.
|
| https://www.youtube.com/watch?v=uS6m37jhdqM&t=1800s
| edtech_dev wrote:
| 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 wrote:
| 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/
| Metalnem wrote:
| 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/dotn...
| tester756 wrote:
| .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 wrote:
| 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 wrote:
| 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 wrote:
| I know, so sad, could have been a great opportunity.
| pjmlp wrote:
| 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.
| thewebguyd wrote:
| > .NET nowadays has a serious adoption problem
|
| It's seriously going to make people question the future of
| the platform. Look at Microsoft's actions, not their words.
|
| TS Compiler: Go New TUI Editor: Rust Winget: C++ (this
| would have been a great candidate for .NET)
|
| At least PowerToys is C#.
|
| .NET is great, but why isn't it good enough for Microsoft?
| The company that historically has had such a strong culture
| of dogfooding.
| reactordev wrote:
| The issue was in the beginning they didn't think interop
| with C/C++ was value add. People complained and they
| added "Managed C++" which unfortunately influenced
| C++03's design a lot. It wasn't until C++11 that
| Microsoft gave up. You couldn't effectively interop with
| C++ without writing a managed C++ wrapper, which only
| worked on windows. They added support for P/Invoke to aid
| in Win32 calls (shell.dll, user32.dll) as a simple fix
| and we went nuts for it. Wrote wrappers using P/Invoke
| and a config map nightmare of which dll's, or dylib's, or
| so's, you needed to get the form to show.
|
| Fast forward to today... Rust can interop with C
| natively. Go can as well, though you're bringing your
| luggage with you with CGO. .Net hasn't ever really had
| that kind of focus. For one, IL, two, Microsoft saw the
| platform as a cash cow, three, ecosystem lock in allowed
| a thriving "MVP" contractor community.
| lowleveldesign wrote:
| Interestingly, the Rust windows crate is generated from
| an MSIL assembly. And same metadata might be used to
| generate C# bindings thanks to cswin32 [1] project. The
| meta-assembly generation (Win32 metadata project) is
| based on clangsharp and it's fairly straightforward to
| generate interop code for native Windows libraries. Some
| time ago I described this process on my blog for the
| detours library [2]
|
| [1] https://github.com/microsoft/CsWin32
|
| [2] https://lowleveldesign.org/2023/11/23/generating-c-
| bindings-...
| reactordev wrote:
| The point is why is another language generating anything
| for C#?
| contextfree wrote:
| Yes, and this approach is an extension of the one taken
| with WinRT metadata which is also ".NET assembly" based.
| pjmlp wrote:
| You are jumping over a few facts there.
|
| P/Invoke was born as J/Direct on J++, it became P/Invoke
| after the lawsuit, and Cool project turned into C#.
|
| Managed C++ Extensions in .NET 1.0 got replaced by
| C++/CLI on .NET 2.0, it was a .NET Core 3.1 milestone to
| support it, and has recently been updated up to C++20,
| minus modules.
|
| Still heavily used among .NET community on Windows.
|
| Meanwhile the native C++/CX and C++/WinRT, both failed
| their adoption efforts.
| contextfree wrote:
| Windows and Office never adopted .NET for client code in
| the first place except for the Longhorn period in the
| mid-00s, which burned them and put them off it. If that
| didn't stop .NET in the two decades between then and now,
| I'm not sure why it would today. Actually, Windows is
| just now starting to adopt C# now that AOT is supported
| (I think the new native Copilot app is C#).
| Kwpolska wrote:
| Many Windows Server admin tools (such as Server Manager
| or Virtual Machine Connection) and MMC snap-ins (e.g.
| Event Viewer, Hyper-V Manager) are written in .NET
| Framework 4. PowerShell is .NET Framework 4. Everyone's
| favorite bloated IDE (Visual Studio) is .NET Framework 4
| as well.
|
| In the Office land, Excel's Power Query is .NET Framework
| 4.
|
| Adopting the modern .NET is probably harder due to its
| lifecycle.
| 9cb14c1ec0 wrote:
| Not sure I agree on the adoption problem. A few medium
| sized client projects are nothing compared to the massive
| internal .NET codebases Microsoft has that run some of
| their largest services.
| pjmlp wrote:
| .NET team members have acknowledged this on podcast
| interviews, .NET Rocks, Nick Chapsas, The Unhadled
| Exception, among possibly others.
| cogman10 wrote:
| I blame historic microsoft for their anti-oss stance. It
| kneecapped the .net ecosystem for over a decade and created
| an attitude of "if it isn't in .NET, I won't use it".
| reactordev wrote:
| I agree as well. The hostile attitude towards OSS under
| Ballmer led to this. Nadella had the correct approach and
| a year later, started repairing those bridges, joining
| the Linux Foundation.
| pjmlp wrote:
| Many things under Satya also feel like good old
| Microsoft, like lack of GUI frameworks for GNU/Linux,
| killing VS4Mac after the rewrite, dotnet watch drama,
| profiling tools being VS only,...
| runevault wrote:
| MAUI not supporting Linux feels like such a huge whiff.
| It is clearly possible to get at least decent cross
| platform support that includes linux in .net considering
| Avalonia exists.
| reactordev wrote:
| VS4Mac deserved to die, that was Mono Code aka Xamarin
| and it was terrible. No offense to Miguel, mono is
| amazing, but the IDE they made was horrid.
|
| Microsoft was asleep at the wheel the last decade of
| Ballmer, leaning too heavily on their Xbox Studios and
| Enterprise Cloud to care about desktops. They gladly let
| Mac take office share as "no enterprise software
| developer would ever choose a Mac". Those famous Mac vs
| PC ads.
|
| The GUI development story has plagued us for a long time.
| No one wants to take on the challenge of a unified user
| interface spec. Why? Because it will always be wrong -
| ever changing - and a giant suck of corporate resources.
|
| It's better to let each team think of their own way of
| doing things. Then, they can choose the best of them and
| release them as frameworks (WPF) only to be abandoned by
| the next regime change.
|
| MAUI, UWA, Metro, WPF, all an attempt to save what effort
| they have made. Ultimately, everyone loves their Electron
| apps, so HTML has become to new UI paradigm. They move
| too slowly. Convinced "they know better than you" and
| will spend the next 5 years hyping up the next XML
| abomination.
| pjmlp wrote:
| No it wasn't any longer, that is why the rewrite took
| place.
|
| I rather use XAML, if given the choice.
| pjmlp wrote:
| That has certainly played a role, however that is common
| to Windows development culture in general.
|
| The 3x "Developers !" meme isn't for nothing, Microsoft
| just like Apple (and NeXT), always a full stack
| development experience story.
|
| Everything that one needs is there on the full Visual
| Studio Professional, and then there was the ecosystem of
| small indie developers and MS Partners building on top of
| that.
|
| That is quite different from UNIX FOSS culture, and has
| also been a friction point to those that went Apple
| without understanding that also have that on their DNA,
| regardless of OS X foundations.
| mathverse wrote:
| I would not touch C# unless you are already using it.
| Microsoft proves over and over it cannot be trusted in what
| they say. Watch what they do:
|
| - basically dont use ant UI framework they say is the
| future and they are not using themselves - be vary of the
| future of some of it stuff like C#
| reactordev wrote:
| Oh I learned this the hard way. Managed DirectX, XNA,
| Creators Club, Windows Store, shared profit motive, fair
| business practices, Project Natal/Kinect, Azure, and
| finally... .Net. Yup, Microsoft loves developers... loves
| their subscriptions.
| rictic wrote:
| What's Omit refer to in this context?
| reactordev wrote:
| The 14,000~ instances of _T?_ or ___
| pjmlp wrote:
| On my little enterprise bubble, the only place remaining for C
| and C++ is writing native libraries to be consumed by managed
| languages, or bindings.
|
| The last time I wrote pure C++ applications at work, was in
| 2005.
|
| Libraries still regularly.
| Const-me wrote:
| For the last few years, I've been developing CAM/CAE software
| on my job, sometimes embedded Linux.
|
| Same experience: last time I developed software written
| entirely in C++ was in 2008. Nowadays, only using C++ for
| DLLs consumed by C#, for 2 reasons: manually vectorized SIMD
| for CPU bound numerical stuff, and consuming C or C++
| libraries like GPU APIs, MS Media Foundation, or Eigen.
| jiggawatts wrote:
| Sometimes I feel like there ought to be a Hacker News like
| forum for us dinosaurs stuck in the Enterprise tarpit.
| Instead of talking about Elixir and AWS startup credits, we'd
| complain about the weather and legacy CORBA components.
| rafaelmn wrote:
| Since you mention great CLI - is there a CLI tool that is
| free/cross platform that works like prettier ? I found
| https://csharpier.com/ but have never heard of anyone using it.
|
| Also not sure how it works with linters like roslynator or
| stylecop ?
|
| This is something I miss very much when coming back from TS,
| other languages also have better formatters. C# is very tied to
| editors/IDEs which is a nightmare in teams where some people
| use vs/vs code/rider
| Cu3PO42 wrote:
| dotnet format [0] exists and is maintained by the .NET team.
| It is different from Prettier in that it is much more
| configurable, but it gets the job done for us. It does
| integrate language services and can automatically apply code
| fixes for custom analyzers. I have not explicitly tried
| roslynator or stylecop, but I suspect this would work as
| expected.
|
| [0] https://learn.microsoft.com/en-
| us/dotnet/core/tools/dotnet-f...
| rafaelmn wrote:
| > It is different from Prettier in that it is much more
| configurable
|
| I only tried it briefly but found it was waaay to lenient
| with the amount of variance in style it left unchanged (eg
| line breaks for function parameters) - can it get
| configured to produce consistent formatting like prettier ?
| Cu3PO42 wrote:
| It can be configured to be much more aggressive with
| formatting, but I'm not certain if you can force it to
| produce the exact same output for any possible whitespace
| in the input.
| eterm wrote:
| I think there are also a lot of default rules which
| aren't enforced until they're bumped up in severity in
| the .editorconfig.
|
| Also it can hook into roslyn analyzers, so if you want a
| more opinionated analyzer then stylecop analyzers (
| https://github.com/DotNetAnalyzers/StyleCopAnalyzers)
| would be an option, although I haven't used it myself for
| a long time.
| jswny wrote:
| The problem is that dotnet format is horribly slow. So much
| so that it's only useful as a precommit hook
| mguijarr wrote:
| Hi! I use csharpier, it does the job - I included it as a
| preliminary check in our CI pipeline for a step of merge
| requests quality assessment. It is the closest tool I found,
| that ressembles prettier. You should definitely give it a
| try.
| siws wrote:
| I've been using csharpier for almost a year now and it's
| amazing. Because it's opinionated, you don't have the space
| to overthink it, you just use it.
|
| Besides, I really like its formatting style.
| Merad wrote:
| Csharpier is the best option available. I've been using it
| for 3-4 years now and had success getting it adopted at my
| last two companies on greenfield projects. It's not exactly
| an unknown tool - nearly 2k stars on Github. But a lot old
| school .Net companies just don't seem to have much interest
| in auto formatters because they've been working without them
| for a long time.
|
| If you're using csharpier you don't need to use Roslynator
| formatters. No issue with the analyzers package. The
| csharpier docs have info on what StyleCop rules need to be
| adjusted so they can work together. Personally I don't use
| StyleCop anymore as it seems to be fairly dead, and I don't
| really feel the need for things like enforcing file layout or
| naming.
|
| Edit: Also I will add that unless the landscape has changed
| recently, I believe csharpier is the only C# tool that has
| deterministic formatting good enough to enforce code
| formatting checks in CI.
| edtech_dev wrote:
| csharpier is great. It is what "dotnet format" should be.
| atombender wrote:
| Do you know about any sizeable open source projects written in
| C#, other than what Microsoft has produced? I rarely come
| across anything written in it.
| whoamii wrote:
| Unity?
| atombender wrote:
| Is Unity open source?
| 369548684892826 wrote:
| Jellyfin / Emby
|
| A lot of the *arr tools like Sonarr
|
| Bitwarden and Keepass
| majora2007 wrote:
| Kavita (self hosting for books/comics)
| Alupis wrote:
| It's a curious thing, the .NET ecosystem. The overwhelming
| majority of it's ecosystem seems to be dominated by Microsoft
| first-party libraries and frameworks. 3rd party libraries and
| frameworks seem to either get swallowed up by Microsoft,
| killed, or never reach critical-mass.
|
| Often in the .NET ecosystem, it seems there is exactly one
| library or framework for thing $X or $Y. Whereas in the JVM
| ecosystem, you have 30+ logging libraries, 87 different MVC
| frameworks, etc. (yes, I'm being a bit facetious, but you get
| the point).
|
| I imagine .NET developers often think this is a good thing,
| in regard to their ecosystem. No guessing what to use, just
| go with the "blessed" path and don't think about it. And, to
| that end, there is some obvious merit to this.
|
| However, I feel the .NET ecosystem loses out on cross-
| pollination of ideas. There's zero possibility Microsoft's
| employees just happen to make the best frameworks and
| libraries... there _should_ be many web frameworks - each
| competing for mindshare and trying to out-innovate each
| other, each with their own pro 's and con's, etc.
|
| So, while .NET might be technically open source, it still
| feels rather like a closed source ecosystem, controlled by a
| single corporate entity.
| cogman10 wrote:
| That because that's the environment MS nurtured for over a
| decade. They were openly hostile to things like nuget up
| until like 2016 or so.
|
| They purposefully made it painful to venture out of the MS
| ecosystem.
| mattmanser wrote:
| It's weird you using logging as there used to be 3/4
| different libraries people used (nlog, log4net, elmah,
| another one I forget?).
|
| Then serilog came out and pretty much everyone switched to
| that in a very short period.
| legulere wrote:
| There are several logging libraries for .net as well,
| microsoft even lists them: https://learn.microsoft.com/en-
| us/dotnet/core/extensions/log...
|
| Libraries getting swallowed up is not so bad as it sounds.
| For instance for web frameworks there was a phase of
| experimentation with projects like Nancy that inspired
| changes for asp.net core. There is still alternatives like
| fast endpoints.
|
| Also you have things happening like integrated
| system.text.json replacing newtonsoft.json that over time
| took on some cruft.
| 75345d4c wrote:
| Why would anyone make a .NET open source library when
| Microsoft is quick to squash anything that is actually
| useful with their own open source implementation?
|
| Microsoft still has some lessons to learn about fostering
| an active open source ecosystem -- of course, unless they
| are intentionally suppressing it in .NET.
| Nelkins wrote:
| Akka.NET and AvaloniaUI are two big ones.
| edtech_dev wrote:
| I'll add Orchard CMS to this list. Also a lot of the seven
| seas software.
| tracker1 wrote:
| Can't speak for FLOSS, but I've worked on massive projects in
| various Banking, Govt and eLearning spaces. I've never really
| hurt for library support via NuGet either. It's honestly not
| always my first choice, but pays the bills.
|
| I mostly just dislike a lot of the excessive use of
| "Enterprise Patterns" for projects that don't come close to
| actually needing them.
| zigzag312 wrote:
| https://github.com/MonoGame/MonoGame (runs even on consoles,
| which is rare for open source game frameworks and engines)
|
| https://github.com/SubtitleEdit/subtitleedit
|
| https://github.com/jellyfin/jellyfin
|
| https://github.com/AvaloniaUI/Avalonia
|
| https://github.com/bitwarden/server
|
| https://github.com/unoplatform/uno
|
| https://github.com/files-community/Files
|
| https://github.com/NickeManarin/ScreenToGif
|
| https://github.com/DevToys-app/DevToys
|
| https://github.com/d2phap/ImageGlass
|
| https://github.com/ShareX/ShareX
|
| https://github.com/duplicati/duplicati
|
| https://github.com/OpenRA/OpenRA
|
| https://en.wikipedia.org/wiki/Ryujinx
|
| https://sourceforge.net/projects/keepass/
|
| https://github.com/orchardcms
|
| https://github.com/piranhacms/piranha.core
|
| https://github.com/umbraco/Umbraco-CMS
| HeliumHydride wrote:
| https://github.com/SM64-TAS-ABC/STROOP
| vizzier wrote:
| https://github.com/quozd/awesome-dotnet
| orphea wrote:
| Ryujinx, a state-of-the-art Switch 1 emulator, was open
| source and written in C#
| legulere wrote:
| Bitwarden
| louthy wrote:
| Not sure what your definition of sizable is. But if it's just
| physical size of repo then my language-ext project [1] is
| about half a million lines of code, ~7,000 stars, and ~25
| million downloads.
|
| We are out there :)
|
| [1] https://github.com/louthy/language-ext
| radicalbyte wrote:
| I've been using it since 2002 so you can imagine my opinion
| when jumping to other languages. They've been very good to
| steal all of the things that worked from other languages and
| constantly iterate on their core infrastructure and language.
| Ygg2 wrote:
| > .NET was the most sane programming ecosystem that I worked
| in.
|
| Having written libraries in .Net I fully disagree with that
| notion.
|
| First insanity is figuring out what in the fuck you need to
| support. .Net framework or .Net standard or .Net Core or Mono
| (or .Net Duplo or .Net dot nes :P).
|
| Second is the Source generators. I swear using t4 templates is
| the saner option. I've had cached artifacts appearing out of
| the fucking nowhere like unkillable zombies despite closing the
| Rider, clearing its cache, and killing build server.
|
| Third is the availability of packages. In Rust and Java there
| are like several libs for anything (even if C bindings).
| wvenable wrote:
| > First insanity is figuring out what in the fuck you need to
| support.
|
| Since I no longer support .NET Framework, it's just .NET now.
|
| .NET was two platforms for a while and they did a lot of
| weird stuff to make that work (.NET standard) but it's been
| one platform for many versions now so that specific
| difficulty can mostly be ignored.
| meibo wrote:
| Most C# libraries I use are outdated, crappy and do just a
| little less than what I need. Also, most Rust libraries I try
| to use are outdated, crappy and do just a little less than
| what I need. Maybe what I need is niche but my experience is
| pretty similar in that regard.
| Alifatisk wrote:
| One-shot execution looks exciting, what problems does it solve?
| Less cluttering in the environment?
| pjerem wrote:
| Scripting, CLI tools ...
| chusk3 wrote:
| 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 wrote:
| I prefer .Net Framework 4.8 Longer lifetime than any .Net
| version.
| brokencode wrote:
| 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 wrote:
| With all the dependencies that maybe getting an update to the
| new .Net version, yes.
| ewoodrich wrote:
| 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 wrote:
| I don't think they introduced any breaking changes after
| .NET 6
| Salgat wrote:
| 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 wrote:
| Every version had breaking changes, they could not affect
| you too much though: https://learn.microsoft.com/en-
| us/dotnet/core/compatibility/...
| starik36 wrote:
| When I need to send someone an app, I usually use .NET
| Framework 4.8 because I know it's already installed on every
| recent version of Windows. This way all I have to distribute
| is a single very small exe. No need to package a framework
| with it.
|
| Similar feat with .NET core usually results in a 70-80MB
| executable.
| SirMaster wrote:
| Is 70-80MB really a big deal to distribute in 2025?
|
| Also if you use trim unused code and compress the
| executable in my experience it's usually a lot smaller than
| this.
| nic547 wrote:
| .NET LTS is on a 2-year cycle, isn't it?
|
| I've worked in .NET shops with very niche WPF/WinForms
| applications where customers were years behind with our
| software/major .NET Framework releases.
|
| I don't think it's a technical challenge, more a cultural
| one.
| WorldMaker wrote:
| A shift in those cultural dynamics is that you can ship the
| current .NET LTS with your app (or even STS if you feel
| like making that sort of security support SLA with your own
| clients). You aren't relying on their Windows Update habits
| (or lack of them) or having to install a big .NET installer
| that might break their other apps.
|
| They may still get left behind on an older version of your
| software because they want to be, but their relationship to
| Windows is no longer the big excuse/reason to skip updating
| to your latest that it used to be.
| brokencode wrote:
| You are right that it's on a 2 year cycle. Though there is
| support for 3 years, so you could safely put off an upgrade
| for up to a year if there are breaking changes one release.
| HumanOstrich wrote:
| Yea that's why I write all my programs in C using the win32
| APIs. It has a lifetime even longer than .NET Framework 4.8.1!
| I'll never have to change or adapt to new things. /s
| croes wrote:
| I change things if it's necessary, not for the sake of using
| the newest version.
|
| Now I have to update software and all its dependencies
| without a real benefit.
|
| It's equivalent of buying a new PC because MS tries to force
| Windows 11.
|
| Lets waste lots of time and resources for nothing.
| edtech_dev wrote:
| Just the amount of perf improvements they have added since
| .NET 4.8, year after year, is staggering.
| Merad wrote:
| I've upgraded apps from every version since .Net Core 2.0. The
| upgrades always take a few hours, maybe half a day (with the
| exception of 2.0 to 3.0 which took a few days - many breaking
| changes). It's well worth a few hours per year to get the
| advantages of newer languages features, enhancements in Asp.Net
| Core, security and performance enhancements in the .Net
| Runtime, etc.
| giancarlostoro wrote:
| 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 wrote:
| This thing has barely changed in the ~30 years I've been using
| it. There's definitely room for some more improvements.
| sumtechguy wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jcotton42 wrote:
| VS2017 was the introduction of the modern VS installer that
| is _way_ faster than the prior ones.
| edtech_dev wrote:
| Have you tried Rider?
| giancarlostoro wrote:
| Yes, it was a bit rough originally, but they've managed to
| make it better, sadly some employers do not want to buy into
| JetBrains.
| JaggerJo wrote:
| Just buy a Rider license. Never looked back.
| vyrotek wrote:
| My guess is we'll know soon. Maybe at VS Live next week?
|
| > "Stay tuned for more details later this summer about what's
| coming next for Visual Studio..."
|
| https://learn.microsoft.com/en-us/visualstudio/releases/2022...
| jug wrote:
| 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...
| munchler wrote:
| One of many examples of C# following in F#'s footprints years
| later. F# deserves a higher profile in the .NET ecosystem.
| eyegor wrote:
| 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 wrote:
| 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
| recursive wrote:
| I've wanted this for a long time. After reading this link, and
| the MS release announcement, I still don't understand what a
| "tool" is, or how you can use `tool exec` to run a single *.cs
| file. Is there a straight-forward recipe anywhere for doing
| this targeted at absolute simpletons?
| banashark wrote:
| Well if you're familiar with the node ecosystem it's a
| corollary for npx/bunx/etc.
|
| It is so that folks can build and run "tools" that are
| executed, utilizing the nuget ecosystem.
|
| Relevant links in the dotnet docs (was just a quick google
| away):
|
| * https://learn.microsoft.com/en-
| us/dotnet/core/tools/global-t...
|
| * https://learn.microsoft.com/en-
| us/dotnet/core/tools/global-t...
|
| It's actually a top-level doc section in the primary dotnet
| docs (https://learn.microsoft.com/en-us/dotnet/).
|
| To boil it down: you create a console app, add a couple of
| attributes to the solution file
| (https://learn.microsoft.com/en-
| us/dotnet/core/tools/global-t...). Packaging and publishing
| to nuget (if you want to share with others) is via `dotnet
| pack` and `dotnet nuget push` with some flags.
|
| I do have to say it's actually very well documented.
| recursive wrote:
| Sorry for being unclear. Using tools isn't my goal. I want
| to run a single *.cs file from the console. It may be
| possible to achieve this using tools, but I don't know how.
| I did read the resources I could find, and didn't find any
| information about this.
| electroly wrote:
| "dotnet tool exec" is not that feature; you're thinking of
| https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
| which they added to "dotnet run". "dotnet run my-cool-thing.cs"
|
| "dotnet tool exec" is so you can run third party command line
| tools like csharpier that previously required "dotnet tool
| install" before you could use them. For example, in
| https://csharpier.com/docs/Installation you can now simply do
| "dotnet tool exec csharpier". This is like "npx" in the
| JavaScript world.
| Salgat wrote:
| dotnet run *.cs is my favorite new feature for scripting. It
| has basically replaced powershell for me. It's trivial to
| script powerful operations now.
| SeriousM wrote:
| I guess LinqPad will lose some users to this feature.
| tracker1 wrote:
| Now I'm curious if C#/.Net 10 is smart enough to ignore the
| shebang line. Personally, I've tended to use Deno/TS for my
| more advanced shell scripting... the main runtime is a single
| executable that works fine in user context, and dependencies
| can be loaded/cached at first run.
|
| Of course, with C# as a shell script, you'd likely be limited
| to just in the box libraries or have to setup a project for
| sake of running a script, like I've had to do with Node or
| Python stuff.
| Salgat wrote:
| https://devblogs.microsoft.com/dotnet/announcing-dotnet-
| run-...
|
| https://devblogs.microsoft.com/dotnet/announcing-dotnet-
| run-...
|
| "dotnet run app.cs" natively supports shebang lines and
| nugets. The only requirement is to make sure the .net sdk is
| installed on your computer.
| ZenoArrow wrote:
| > I only really wish C# would've been directly integrated as an
| alternative scripting language in PowerShell.
|
| You can embed C# in PowerShell scripts, and you have been able
| to do so for a long time. This webpage has a couple of examples
| of how this can work:
|
| https://blog.nuvotex.de/run-c-inside-powershell/
| sergiotapia wrote:
| 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 wrote:
| The version numbers used to increase much more slowly. Since
| the .NET (modernized / cross platform) core "track" the version
| number increments every year.
| WorldMaker wrote:
| 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 wrote:
| https://learn.microsoft.com/en-
| us/lifecycle/products/microso...
|
| The last 5 version have been released a year apart, in
| Novembers.
| majora2007 wrote:
| 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 wrote:
| 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.
| WorldMaker wrote:
| > it's still the weird Visual Studio format
|
| .NET 9 (and VS2022) added support for the SLNX replacement
| format to replace the old weird solution format:
|
| https://devblogs.microsoft.com/visualstudio/new-simpler-
| solu...
| oneplane wrote:
| Yep, but you still can't say "compile and link everything
| in this tree". Technically, the language can, but the
| framework assumes specific compiler, linker and layouts on
| the filesystem so at that point you can't. It really wants
| that editor-related stuff to be part of the framework, and
| everything else has to bend for it.
| WorldMaker wrote:
| A Project file today can just be a full tree glob. New
| projects start out in that form. The `dotnet` CLI is
| still going to assume some default output paths as it
| builds object files and executable assets, but those are
| all easily flag configurable today. (I've done some wild
| CI things.)
|
| You don't have to use a Solution at all with the CLI, you
| can do everything in a single Project and one full tree
| glob. (Technically you haven't need a Solution with
| Visual Studio for a long while either, if you don't mind
| it sometimes auto-creating them at compile time, and even
| then you can just .gitignore .sln and not care. But even
| that random auto-.sln file thing has disappeared in
| recent years and Visual Studio has learned more auto-
| workspace tricks from VS Code.)
|
| I have started projects that just did that, started with
| a simple glob-only project and no prescribed file layout.
|
| Yeah, dotnet doesn't let you micro-manage the linker
| specifically, but few languages since C++ _do_ and
| arguably the C /C++ linker sometimes seems as much a bug
| of C/C++ as a feature in modern times.
| qingcharles wrote:
| The biggest change for me has been the ability to deploy my web
| sites to a Linux box instead of having to deal with IIS.
|
| WinForms app development hasn't changed one bit in 25 years.
|
| If you code in C# then they've added some nice new language
| features every year to make your code a little tidier.
|
| And the whole framework is totally open source now, which is a
| bonus.
|
| There's nothing I'm really asking for. It does pretty much
| everything I need these days.
| WorldMaker wrote:
| Favorite recent language feature is a big investment in C#
| pattern matching. It's a big feature from the functional
| programming world rare to see in "Enterprise" languages.
|
| Favorite recent runtime feature is all the cool low level stuff
| opened up by Span<T> (and Memory<T>). It has a similarity to
| Rust borrowing, but well integrated into the CLR's existing
| type system. It has opened all sorts of performance code
| possibilities that is still memory-safe/type-safe with fewer
| needs for falling back to "unsafe" operations. This is not just
| exciting because it is an interesting playground if you like
| low-level programming, but also because it has been a
| performance flood lifting all boats in the .NET ecosystem. A
| _lot_ of code over the last few years has gotten easy
| performance boosts by _just_ recompiling (because the compilers
| were taught to prefer Span /Memory overloads when they get
| added; no change to C# or F# code, just the compiler picking a
| new performance path).
| debugnik wrote:
| Definitely change for F# code, some of those Span overloads
| broke type inference. Also, certain APIs even removed their
| non-Span overloads between .NET versions, which was a
| straight up breaking change for every language other than C#.
| cyphax wrote:
| My favorite feature, especially considering the past of
| "heavily tied into Visual Studio" is the platform independent
| nature of (most of) "modern" dotnet. That is to say, I run
| Fedora on my laptop, and I do not want Windows, yet I don't
| feel like a second class citizen and dotnet runs well and is
| available from repositories that Microsoft provides for various
| Linux distributions (it just hit me how strange this is, for
| _Microsoft_ to offer official repositories for Linux operating
| systems...).
|
| I also really like that its development is fairly open (it's on
| github). From a more technical point of view, I think C# is a
| slightly better Java. A pretty nice language overall. It's not
| gui-or-nothing with dotnet core so it's not too difficult to
| create workflows for ci/cd pipelines, although the .net
| framework solutions we still have aren't too much harder to
| script: msbuild is pretty capable.
| debugnik wrote:
| > NET 10! Jesus, 10!
|
| Well, spiritually this is the 13th(?) major version of .NET
| (possibly more if we count Silverlight's runtime). You missed
| the part when there was .NET Core 1-3 alongside the old .NET
| Framework 4.8., and then they skipped Core 4 and stopped
| supporting Framework so they could finally fix their naming
| scheme.
| devwastaken wrote:
| 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 wrote:
| It is fully open source so... who cares?
| dimaaan wrote:
| MIT license: https://github.com/dotnet/roslyn
| jcotton42 wrote:
| > 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 wrote:
| They should fix github issues and write in-depth tutorials,
| instead of AI features or minimal API.
| smackeyacky wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-30 23:00 UTC)