12 ms·
Reinventing how .NET builds and ships (again)
- yodon 11mo agoMust have been an amazing effort to be involved in.
- N_Lens 11mo ago.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node). I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
- SamuelAdams 11mo agoI love working with dotnet, but lately I’ve been writing more backend applications in Python. The code is simpler, testing is simpler since method privacy doesn’t really exist, and code is quicker to deploy because you do not have to compile it. This could also change but in my experience AI is better at generating Python code versus dotnet.
- martinald 11mo agoProblem is though Python is slow at runtime. May not matter for many use cases, but I've worked with a lot of startups that suffered terrible reliability problems because they chose Python (or Rails, or Node to some extent) and the service cannot handle peak time load without a lot of refactoring and additional app servers. Depending on your framework Python is at best ~3x slower (FastAPI) and at worst ~20x (Django) than asp.net on the techempower benchmarks, which maps pretty well to my real world experience.
- casper14 11mo agoCan confirm. Just finished load testing a FastApi service. Now the biggest selling point is that a lot of real backend never experience the level of load where this actually matters
- array_key_first 11mo agoI work for a very large company that has a mostly SSR monolith written in PHP. Modern PHP is a joy, and it's much faster these days, but performance is still a problem. It was chosen over 25 years ago, and I'm sure they thought the same thing about never getting the amount of load they eventually got. Modern PHP is virtually indistinguishable from dotnet, with some php-isms sprinkled on top. They should've chosen dotnet all those years ago.
- mynameisash 11mo agoI don't spend a lot of time building services, but the last few I've done, I actually went straight to Rust. The downside is that it's quite slow to develop -- I probably don't have the knowledge that others do, but it seems that frameworks could really use some work. That said, I love that I can find and fix most my problems during development. Building a service in Python means I'm constantly fixing issues in production. .NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects.
- sasmithjr 11mo ago> .NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects. Have you given F# a whirl?
- mynameisash 11mo agoYou know, I tried F# like eight-ish years ago, and I loved it, but I couldn't break into doing it with enough regularity and depth that it made sense for me. I still do a decent amount of C# at work, and with my experience in Rust (algebraic data types, etc.), I imagine that F# would really help out a lot in our .NET code.
- tracker1 11mo agoTake a look at FastEndpoints library for API development... definitely improves the experience a lot IMO... That said, Rust+Axum is pretty nice as well.
- WD-42 11mo agoMost web apps are waiting on the DB anyway. Rarely have I seen the speed of the actual framework make any meaningful difference.
- jtbaker 11mo agoNot saying that it’s necessarily the right choice, but it opens up contributions to code to a broader user base and making those rapid iterations that tools like fastapi allow can be pretty important when proving out a concept early on. Horses for courses… also, a Horizontal Pod Autoscaler and Load Balancer setup is pretty cheap.
- UltraSane 11mo agoI'm moving from Python to Java because of how much easier it is to actually use all CPU cores in Java and strict typing prevents so many bugs and it is much faster. I don't think it is actually that much more complicated than Python in 2025.
- martinald 11mo agoAgreed. It's sort of crazy how little people understand about multicore software design given nearly everyone is using machines with >8 CPU cores these days (even a cheap android phone tends to have 8 cpu cores these days). In python and node it is _so_ painful to use multiple cores, whereas in .net you have parallel for loops and Task.WhenAll for over a decade. Java is similar in this sense that you don't have to do anything to use multiple cores and can just run multiple tasks without having to worry about passing state etc between 'workers'. This actually becomes a really big problem for web performance, something I'm deeply passionate about. Not everything is just IO driven holdups, sometimes you do need to use a fair bit of CPU to solve a problem, and when you can't do it in parallel easily it ends up causing a lot of UX issues.
- UltraSane 11mo agoEven Guido van Rossum admits that if he had known how common high core count CPUs would become he wouldn't have chosen to use the GIL
- fijiaarone 11mo agoOn most cloud deployments, you get one shared “virtual” core — whatever that means.
- UltraSane 11mo agoNo you get how ever many you choose and are willing to pay for. 1vCPU is not good for very much.
- zem 11mo agoout of curiosity, why not kotlin? I had the impression it was the jvm language to reach for by default these days.
- sanex 11mo agoIf you don't want your methods to be private make them public?
- carry_bit 11mo agoJust make them internal and use [InternalsVisibleTo] on the assembly.
- chokolad 11mo ago> I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem. Can you elaborate a bit? This article talks about internal machinery of building .net releases. What does that have to do with "this churn", whatever that is?
- da_chicken 11mo agoWhat do you mean? The .Net ecosystem has been generalized chaos for the past 10 years. A few years ago even most people actively working in .Net development couldn't tell what the hell was going on. It's better now. I distinctly recall when .Net Framework v4.8 had been released and a few months later .Net Core 3.0 came out and they announced that .Net Standard 2.0 was going to be the last version of that. Nobody had any idea what anything was. .Net 5 helped a lot. Even then, MS has been releasing new versions of .Net at a breakneck pace. We're on .Net 10, and .Net Core 1.0 was 9 years ago. There's literally been a major version release every year for almost a decade. This is for a standard software framework! v10 is an LTS version of a software framework with all of 3 years of support. Yeah, it's only supported until 2028, and that's the LTS version.
- Rohansi 11mo agoThe only chaos occurred in the transition from .NET Framework to .NET (Core). Upgrading .NET versions is mostly painless now because the breaking changes tend to only affect very specific cases. Should take a few minutes to upgrade for most people.
- martinald 11mo agoThis isn't really anything user facing. It's just yet again an example of why monorepos are better.
- jerezzprime 11mo agoAnything is a monorepo if you submodule hard enough lol
- mcny 11mo agoWhy don't people use subtree? https://www.atlassian.com/git/tutorials/git-subtree https://www.atlassian.com/git/tutorials/git-subtree
- Smaug123 11mo agoThe .NET source build team looked at subtrees (https://github.com/dotnet/arcade/issues/10257#issuecomment-1205090811 https://github.com/dotnet/arcade/issues/10257#issuecomment-1...). > Introduces a very messy and complex history which would not work for the repo of our size > Apparently the support in git is buggy and can lead to problems in the repo (the SO is full of examples) > Doesn't support cloaking (I think by "cloaking" they are referring to https://github.com/premun/dotnet/blob/766c564dd379e634c3873943174530be3181e7b2%5E/docs/VMR-Design-And-Operation.md#repository-source-mappings https://github.com/premun/dotnet/blob/766c564dd379e634c38739... )
- tonyhart7 11mo ago.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh
- smt88 11mo ago.NET has a far better developer experience than Node and is nearly as fast as Rust if written for performance, certainly much faster than Node or Python
- tonyhart7 11mo agonumbers speak for themselves
- zihotki 11mo agoWould you mind providing yours as well as benchmarks used? All benchmarks I could find point to a different picture than described in parent comment
- oaiey 11mo agoNumbers are inflated not by choice but by force. Node is not a choice but a consequence of frontend heavy work. And JavaScript was made good using typescript by the guy who also created C#. Same goes with Python with its data science and ML/AI background. And the general malus is Microsoft as a company. In summary: it is not the tech. It is the landscape.
- array_key_first 11mo agoTS is still much more annoying to use than monotonically typed systems like dotnet, and it's also much less safe. TS drags JS into the world of modern languages, but it's not good enough IMO.
- smt88 11mo ago.NET is far more widely used for desktop and web backends. Taylor Swift is the most popular artist of all time. Is she also the best and your favorite? Popularity is important, but it doesn't mean anything by itself.
- anonymous908213 11mo agoNot sure about the past tense here. .NET is still excellent and getting even better with every release. What instability are you talking about? There was the leap to .NET Core which was majorly breaking, but that was almost 10 years ago now.
- frank_nitti 11mo agoIf they’re in a team similar to some I’ve worked with, engineers are barely getting comfortable with the shift away from .NET Framework (!) There are legions of developers for whom Visual Studio on Windows is the only place they have ever been comfortable. And upgrading between versions of .NET is a point-click exercise between the various UIs (Visual Studio Installer, “Get New Components or Features”, and the NuGet package manager) The advent of .NET Core happened to coincide with initiatives to adapt: * toward the cloud and away from IIS and Windows Server * toward Git and away from TFS * toward remote CI/CD and away from “drag my files into inetpub” * toward SPAs and away from ASP.NET XAML programming (Blazor notwithstanding) * toward a broader toolkit where the familiarity with OSS and open specs is advantageous, and away from Visual Studio as the center of the universe (though it still arguably reigns supreme in its class of IDEs) Coming from the Linux/Docker world before going deep in .NET, I was both resented and leaned on heavily for these teams’ transitions. Most of my teammates had never read the contents of their .csproj or .sln files, or run a build command from a terminal and read its log output. They were annoyed by my requests to do so when helping them troubleshoot; some just rejected the idea outright (“there’s no need to look at VS internals here”, “we shouldn’t need to run DOS commands in today’s world, VS should hable this!”) I can definitely sympathize with developers who were sold on what seemed like a promise that deep VS/IIS/etc knowledge would be the rock-solid foundation for business software for the rest of their careers. During the uprooting process, other promises like “netstandard2.0 will be forever for your core libraries and all future .NET runtimes!” end up with asterisks the following year. I am 100% in agreement that .NET dev team is doing an amazing job, but it’s precisely because of their continued shakeups when they see major opportunities to improve it from the ground up, and probably the same reason that others feel wary of it
- jve 11mo ago
- arnonejoe 11mo agoI love C#. When combined with JetBrains Rider it may be the most satisfying dev experience I’ve had in my career.
- croes 11mo agoIs nuget any different from npm
- smt88 11mo ago.NET churns less than any other major stack. Every upgrade since Core 2 (released in 2017) has been minimally painful or, more recently, painless.
- tracker1 11mo agoSimilar for me, though I had a lot of pain going from Core 2 to Core 3... a couple minor hiccups with .Net 5, but since then nothing of note.
- pjmlp 11mo agoI feel the pain, as polyglot consultant, I would like to see more RFPs asking for .NET skills, unfortunely it seems it is all about nodejs, some Java, and plenty of low code tools (iPaaS). At least exactly due to performance issues, I get some excuses to push for C++ addons in some cases.
- tracker1 11mo agoSince .Net Core 3, I haven't really experienced too many breaking issues that directly affected me... mostly been relatively easy to update my target framework and dependencies. I mean, it's slightly time consuming, but nothing like updating say a React project that's been sitting for even a couple years. I know their release/LTS cycles are now much shorter than the 20+ years that some framework versions have seen, but keeping things "current" hasn't been that hard. IMO, it's just part of maintenance for "rapid" software development. Companies want software in weeks instead of many years of planning, that means ongoing maintenance work.
- whoknowsidont 11mo ago>.NET was a solid choice for backend builds before Node became so popular The problem with the community is that this statement has been said for every version in every era despite how untrue it is lol. No matter what ills or blights .NET will put on your solution the developers will always sing its real or imagined praises. This is the #1 reason I avoid interacting and working with .NET teams because it's still true to this day. Honesty would go a long way.
- cadamsdotcom 11mo ago> We’re asking how much it will cost to build 3-4 major versions with a dozen .NET SDK bands between them each month. Why so many variants?
- martinald 11mo agoWell you've got .NET 8 (LTS), .NET 9 (standard support), .NET 10 (LTS). These are all supported at once. Then you've got the .NET SDK/aspnet/runtime (on x64/arm32/arm64 linux/mac/windows), and also the various SDK packages themselves.
- cadamsdotcom 11mo ago3**4 = 81 builds - but aren’t all of those independent and thus parallelizable?
- martinald 11mo agoNo, read the article. It needs to build some "sub" SDKs to build the final 'full' SDK packages. That's the whole point; they want to get to a state where they can do that.
- ZeroConcerns 11mo agoOh, wow, I didn't expect that the best thing I'd read about software engineering, like, this year would come out of Microsoft! Don't get me wrong: I like .NET, especially its recent incarnation, but until just now, I would have expected its robustness to be an against-all-odds under-the-radar lucky escape from the general enshittification that seems to be the norm for the industry. Reading something like this, which outlines a coordinated effort (diagrams and even a realistic use case for agentic LLM usage and all!) to actually and effectively make things better was a breath of fresh air, even if towards the end it notes that the remarkable investment in quality will not be in full force in the future. Even if you don't care about .NET and/or Microsoft, this is worth reading, doubly so if you're in charge of re-engineering just about anything -- this is how it's done!
- hu3 11mo agoI have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution). And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard to keep state synched between back and front. Feels good to have 3 trillion dollars interested in improving the stack you use and actually care. Developers! Developers! Developers!
- NamlchakKhandro 11mo ago[flagged]
- yndoendo 11mo agoLast time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solutions. I have had too many issues with their frameworks, like WPF, needing to implement Win32 hacks. Example, .Net 9 was the first Windows version that properly returns all network interfaces. Older runtimes only expose Enabled NICs. I still have to maintain Windows 7 support for some solutions.
- vjvjvjvjghv 11mo agoWe are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.
- Limeray 11mo ago
- zem 11mo agoone thing that struck me was that the foundation for this effort was the linux distro build system. in other words, the work they put into making .net open-source and cross-platform eventually made everyone's lives easier.
- oaiey 11mo agoI think .NET is way beyond the situation that they question their open source move. The amount of pull requests and positive outcomes for them in the last 10 years (yeah that long already) is mind blowing.
- zem 11mo agoyeah, I didn't mean that it was evidence the open source move was successful or valuable, more that it showed that the engineering effort that went into the open sourcing also yielded dividends for the project in general
- mmitche-msft 11mo agoAuthor of the post here, We wanted the option for distro maintainers to include .NET in the native distro package feeds. This means that distro maintainers have to build the product, not us, and that means creating a build system that meets their requirements. So you either end up with two build systems, or you try and unify. The only direction that it's feasible to go is towards the Linux distro model. It's the most restrictive. The good news is that the distro model is SIMPLER. It may not be the most performant. A really good distributed system with caching would be far faster. But that's not a solution that's easy to implement or compatible with distro maintainer workflows. Optimizing for simpler in this case is better though. We want the community to be able to participate in a meaningful way. Build for BSD, build for S390x, build and include in distro feeds, etc. We can't feasibly support every platform and scenario that the community wants.
- debugnik 11mo agoI glad to read this. One of my long-term concerns with .NET, compared to other language ecosystems, is the risk that only Microsoft people might know how to build it and port it. Is any distro actually shipping .NET SDK packages built from source?
- Yokohiii 11mo agoI can see that high level overviews of complex systems are useful to get some insights, but in the same way I have the feeling that this mentality of high level, abstract organization is the root of the problem. If you have a complex system and simplify the components into abstractions, you will repeatedly run into difficulties because you've actively ignored the dirty bits. It's an top down approach that tries to tackle all issues, but an bottom up approach could even eradicate myriads of issues.
- deleted 11mo ago[deleted]
- Surac 11mo agoI use c# also to earn my money. Sadly the new custom to hyperinflation in language sugar and framework makes following new things quite hard. Even today starting a new project I choose .net framework 3.5 and syntax. I know this sounds extreme but 3.5 has anything I need to build great software. It also offers a very tested environment. Setting up the software stack is a very easy process. Programmed following v2 runtime also work on v4 runtime so only a simple config file side by side to exe makes it run on any windows machine without any framework deployment.
- oaiey 11mo agoI remember these days. But I have to say: .NET Core and .NET 5+ are awesome. They bring this ease you speak about into the cloud, into Linux, into containers. Obviously with the notable exception of UI development, but there the landscape has turned 5 times since 3.5 was released in 2007.
- Hawxy 11mo ago3.5 is approaching end of life in the next few years, you definitely should not building anything new with it. There's a lot of QoL changes in modern .NET that makes your life as a developer significantly nicer. Even for building windows services, the modern Generic Host model is orders of magnitude better than anything in .NET Framework.
- jmkni 11mo agoI'm shocked that 3.5 is still supported, it came out in 2007!
- jonathanlydall 11mo ago.NET Framework 3.5 is so old it’s not available by default on Windows (maybe not available at all on the latest Windows), you’d probably have to work with ancient developer tooling to work with it, it’s probably unsupported and has security issues. And that’s ignoring how you’re essentially severely handicapping yourself in terms of what is possible. Unless you’re in an environment stuck 20 years in the past (which implies serious security liabilities considering they must be a Microsoft shop), this is a mind bogglingly bizarre strategy.
- truth_seeker 11mo agoBravo, such a well written article. Feeling motivated enough to deep dive into .NET 10
- littlecranky67 11mo agoModern .NET is awesome. In a small side hustle project, I develop a REST API Backend in C# on my macOS using VSCode, and deploy it to Linux for the past 3 years without any issues. I use SQLite, EFCore, Minimal APIs and it is a delight compared to the frontend part - which is NextJS/React/MaterialUI with 50+ (dev-)packages in npm.
- tracker1 11mo agoWould suggest taking a look at the FastEndpoints library if you need anything even slightly more complex... just about my favorite for APIs at this point. A close second would be TS + Hono + Zod-OpenApi and SwaggerUI.. but setting up my context types is slightly more of a pain.
- littlecranky67 10mo agoI used ServiceStack (also REST API) around ~2013 with C#. But in the end, a core benefit of .NET is that it is batteries-included, so I stick with the built-in Minimal API solution. Plus, FastAPIs core selling point seems to be performance and speed - a solution to a problem that I don't currently have with that project, nor will encounter in the near future.
- linkage 11mo agoWhy is Microsoft's developer division among the best in the industry while the rest of the company (except enterprise sales) is the literal embodiment of incompetence and enshittification? How have they prevented the pervasive cultural rot from affecting them?
- 1970-01-01 11mo agoMostly due to politics and chasing the leaders in the industry. The days of looking in the mirror and seeing what they are have been gone since Bill left the job.
- johnzabroski 11mo agoNice article but it seems obvious to me the .NET team should throw away AzureDevOps as the queue wait time is the major bottleneck. Run bare metal build servers. Maybe there are justifications not to do this, but the article skips the elephant in the room.
- mmitche 11mo agoAzure DevOps isn't the cause of the queue time problem. It can run bare metal. The Mac hardware that we run attaches and starts super quickly, for instance. We want clean machines on every job (for compliance and robustness), so we're spinning new VMs on Windows/Linux jobs. We could have hot machines ready to go at all times and eliminate any queue time. There's also machine-learning based model for predictive spin-up. The downside is primarily cost to maintain all the various SKUs needed in a live and ready state. We compromise a bit there.