Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reinventing how .NET builds and ships (again)

devblogs.microsoft.com

Post reply on HN
Print view View original

91–100 of 146 posts

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

#91

Post by Smaug123 »

mcny wrote: post #58
jerezzprime wrote: post #12

Earlier quoted context omitted.

Anything is a monorepo if you submodule hard enough lol

Why don't people use subtree? https://www.atlassian.com/git/tutorials/git-subtree

The .NET source build team looked at subtrees (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/766c564dd379e634c38739... )

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

#92

Post by orphea »

pjmlp wrote: post #73
Rohansi wrote: post #49

Earlier quoted context omitted.

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

Except it is a bummer when one happens to have such specific cases. It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.

You're describing a specific case of working in a big rigid enterprise. It doesn't have anything to do with .NET itself, does it?

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

#93

Post by neonsunset »

cm2187 wrote: post #84
hu3 wrote: post #18

I 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 t…

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…

[dead]

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

#94

Post by jmkni »

Hawxy wrote: post #69
Surac wrote: post #61

I 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 runt…

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

I'm shocked that 3.5 is still supported, it came out in 2007!

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

#95

Post by tonyhart7 »

oaiey wrote: post #77
tonyhart7 wrote: post #56

Earlier quoted context omitted.

[flagged]

Rust is a tool not for application development. It has a huge space in drivers, renderers and other low level places. Node and Python are dynamically typed and at least originally scripting focused. They are not the right choice for many development active which are focused. .NET plays with Go and Java in the same category of use cases. And there it boils down to devs you have. Regards ecosystem: I am at home in both…

I know where .NET fits: game development and legacy Windows apps. Otherwise, we don't need .NET—and let's not forget how HN feels when they have to deal with the MS tech stack.

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

#96

Post by da_chicken »

pjmlp wrote: post #90
lan321 wrote: post #89

Earlier quoted context omitted.

If you can't get permission to update/change IDE, the company processes aren't working at all tbh. Same if cicd is in another department that doesn't give a shit.

That is pretty standard in most Fortune 500, whose main business is not selling software, and most development is done via consulting agencies. In many cases you get assigned virtual computers via Citrix/RDP/VNC, and there is a whole infra team responsible for handling tickets of the various contractors.

Similar story at my prior job. Heck, we still had one package that was only built using 32-bit .Net Framework 1.1. We were only just starting to see out-of-memory errors due to exhausting the 2 GB address space in ~2018.

I love the new features of .Net, but in my experience a lot of software written in .Net has very large code bases with a lot of customer specific modifications that must be supported. Those companies explicitly do not want their software framework moving major supported versions as quickly as .Net does right now, because they can't just say "oh, the new version should work just fine." They'd have to double or triple the team size just to handle all the re-validation.

Once again, I feel like I am begging HN to recognize not everyone is at a 25 person microservice startup.

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

#97

Post by pjmlp »

orphea wrote: post #92
pjmlp wrote: post #73

Earlier quoted context omitted.

Except it is a bummer when one happens to have such specific cases. It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.

You're describing a specific case of working in a big rigid enterprise. It doesn't have anything to do with .NET itself, does it?

Guess where most .NET developers employeers happen to be?

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

#98

Post by smt88 »

tonyhart7 wrote: post #57
smt88 wrote: post #51

Earlier quoted context omitted.

.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

numbers speak for themselves

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

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

#99

Post by UK-AL »

tonyhart7 wrote: post #95
oaiey wrote: post #77

Earlier quoted context omitted.

Rust is a tool not for application development. It has a huge space in drivers, renderers and other low level places. Node and Python are dynamically typed and at least originally scripting focused. They are not the right choice for many development active which are focused. .NET plays with Go and Java in the same category of use cases. And there it boils down to devs you have. Regards ecosystem: I am at home in both…

I know where .NET fits: game development and legacy Windows apps. Otherwise, we don't need .NET—and let's not forget how HN feels when they have to deal with the MS tech stack.

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

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

#100

Post by lan321 »

da_chicken wrote: post #96
pjmlp wrote: post #90

Earlier quoted context omitted.

That is pretty standard in most Fortune 500, whose main business is not selling software, and most development is done via consulting agencies. In many cases you get assigned virtual computers via Citrix/RDP/VNC, and there is a whole infra team responsible for handling tickets of the various contractors.

Similar story at my prior job. Heck, we still had one package that was only built using 32-bit .Net Framework 1.1. We were only just starting to see out-of-memory errors due to exhausting the 2 GB address space in ~2018. I love the new features of .Net, but in my experience a lot of software written in .Net has very large code bases with a lot of customer specific modifications that must be supported. Those companies…

I might be missing something but the combination of 'we mustn't break anything' and 'we can't test it without 2-3* team size' sounds like release deadlock until you can test it..

The migrations where I've worked at have always been a normal ticket/epic. You plan it in the release, you do the migration, you do the other features planned, do the system tests, fix everything broken, retest, fix, repeat until OK, release.

Otherwise you're hoping you know exactly how things interact and what can possibly have broken, and I doubt anyone knows that. Everyone's broken things at first sight seemingly completely unrelated to their changes at some point. Especially in large systems it happens constantly. Probably above 1% of our merges break the nightly in unexpected places since no one has the entire system in their head.

Or you're keeping a dead product just barely alive via surgical precision and a lot of prayers that the surgeon remains faultless prior to every release.

Post reply on HN