Reinventing how .NET builds and ships (again) • Hacker News Board

Re: Reinventing how .NET builds and ships (again)

#141

Post by mmitche » Thu, Nov 27, 2025, 4:37 AM UTC

johnzabroski wrote: post #140

Nice 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.

Azure 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.

Re: Reinventing how .NET builds and ships (again)

#142

Post by debugnik » Thu, Nov 27, 2025, 7:41 AM UTC

johnzabroski wrote: post #139

debugnik wrote: post #129

Earlier quoted context omitted.

Looks like I missed progress during the time I've been away from dotnet, thanks. I still had memories of having to install an MS repo for that.

"old man yells at clouds." :)

Not at all! Looking at the package dates, distros have started shipping their own source builds during 2022-2024, starting with .NET 6-7.

Re: Reinventing how .NET builds and ships (again)

#143

Post by littlecranky67 » Thu, Nov 27, 2025, 8:04 AM UTC

tracker1 wrote: post #108

littlecranky67 wrote: post #88

Modern .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.

Would 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.

I 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.

Re: Reinventing how .NET builds and ships (again)

#144

Post by cm2187 » Thu, Nov 27, 2025, 9:30 AM UTC

johnzabroski wrote: post #137

cm2187 wrote: post #84

Earlier quoted context omitted.

I am not sure what the stats are but I am certain they left behind a huge number of projects. Probably a population that won't be very vocal on HN but that doesn't mean they don't exist. Even for new projects there are problems I run into that force me to use 4.8. Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context whe…

async await works fine to build Excel formulas via RTD Servers. https://excel-dna.net/docs/release-notes-1-9/#asynchronous-a... Just because you think something is hard, doesn't mean it is hard.

RTD functions are a different thing. It may be useful for certain cases but in my usage would break the calculation model, as the calls must be made in a given order, and must be refreshed by the user deterministically. I can also build some more complex workaround, like calling a different process, though the antivirus in the corporate environment I work in is unlikely to like that.

Re: Reinventing how .NET builds and ships (again)

#145

Post by maleldil » Thu, Nov 27, 2025, 10:47 AM UTC

tonyhart7 wrote: post #136

UK-AL wrote: post #99

Earlier quoted context omitted.

Most .net projects are web API, and backend applications.

"Most .net projects are web API, and backend applications." if this year is 2015 then you are right

You have absolutely no clue what you're talking about, mate. .NET is like Java. It's behind critical systems you haven't heard of because they're not flashy or glamorous, so you have no idea how prevalent they actually are.

The other posters are right. Most .NET projects today are backends, where it's used similarly to how Java is used.

Re: Reinventing how .NET builds and ships (again)

#146

Post by zem » Thu, Nov 27, 2025, 6:56 PM UTC

mmitche-msft wrote: post #103

zem wrote: post #21

one 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.

Author 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…

that sounds awesome. having wrestled with complex build setups I'm a big fan of simple and reproducible, though as you say there's definitely the temptation to do things to improve performance at the expense of simplicity.