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

111–120 of 146 posts

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

#111

Post by tracker1 »

fijiaarone wrote: post #37
gregmac wrote: post #35

Earlier quoted context omitted.

> if your source code is based on newer .NET you have to update to a new version each year .NET has a really refreshingly sane release life cycle, similar to nodejs: - There's a new major release every year (in November) - Even numbers are LTS releases, and get 3 years of support/patches - Odd numbers get 18 months of support/patches This means if you target LTS, you have 2 years of support before the next LTS, and a…

Ah, but if you use node.js you get breaking changes every other day from dependencies on dependencies you didn’t even know you had.

The in the box libraries for .Net (even if via Nuget) are much more stable by comparison.

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

#112

Post by tracker1 »

Krutonium wrote: post #34
a1o wrote: post #30

Earlier quoted context omitted.

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

I think it's important to remember that Dotnet projects can use code built for older releases; to an almost absurd degree, and if you don't go to before the .NET Framework divide, you largely don't even need to change anything to move projects to newer frameworks. They largely just work. The .Net platform is honestly the most stable it has ever been.

Going from Core 1 to 2 then 3 had a lot of rough edges, but since then it's been pretty painless.

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

#113

Post by frank_nitti »

jve wrote: post #70
frank_nitti wrote: post #43

Earlier quoted context omitted.

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

Thanks for making me feel like a 10x dev :) Anyways, I work with .NET Framework and .NET. Being a developer is a joy where you can learn daily new tricks and satisfy your curiosity. So to me this reads so alien that people fail to learn new tricks within .NET world. For me it's like a stream of amazement: Ohh, this is so much better with new language features. Ohh, this code is so much more clean. Woa, logging is so…

I love it! And yeah .NET Framework is still critical for some workloads, most notably C++/CLI and WCF for certain apps where deep win32 APIs make their net8.0+ alternatives too much of a headache :)

To temper my comment, the resistance I faced as the new guy brought in to modernize is natural for these engineers who knew their tools and systems well, in their defense. Eventually they warmed up from full pushback to friendly banter “Mr. Linux and command line over here” and accepted that running my little scripts helped address the confusion/frustration of Visual Studio disagreeing with Jenkins/GitHub Actions automations and runtime behavior in Kubernetes.

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

#114

Post by oaiey »

UK-AL wrote: post #99
tonyhart7 wrote: post #95

Earlier quoted context omitted.

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.

By a factor of 1000. Unreal.

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

#115

Post by tracker1 »

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.

On the migrations... read the comments through this thread.. there are many, and none have mentioned any significant pain points at all, just hypothetical ones from people like you who aren't actually actively using it.

As to the CI/CD pipelines... I just edited my .github/workflow/* to bump the target version, and off to the races... though if you're deploying to bare metal as opposed to containers, it does take a couple extra steps.

As to the "permission to install..." that's what happens when companies don't trust the employees that already write the software that can make or break the company anyway... Defelopers should have local admin privs, or a jump box (rdp) that does... or at the very least a linux environment you can remote-develop on that, again, has local admin privs.

I'm in a locked down environment currently, for a govt agency and hasn't been an issue. Similar for past environments which include major banking institutions.

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

#116

Post by tracker1 »

pjmlp wrote: post #97
orphea wrote: post #92

Earlier quoted context omitted.

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?

I've been using .Net since late 2001 (ASP+) including in govt and banking and rarely have had issues getting timely updates for my local development environment, and in the past decade it's become more likely that the dev team controls the CI/CD environment and often the deployment server(s).... Though I prefer containerized apps over bare metal deployments.

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

#117

Post by mmitche-msft »

debugnik wrote: post #104
mmitche-msft wrote: post #103

Earlier quoted context omitted.

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…

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

Yes, Canonical, RedHat, Fedora, Alpine, Centos, and Arch Linux. NixOS and nixpackages too.

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

#118

Post by tracker1 »

frank_nitti wrote: post #43
anonymous908213 wrote: post #14

Earlier quoted context omitted.

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

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

As someone who has actively pushed in the direction of containerized deployments, VS Code with the integrated terminal over VS proper, etc... I love the direction .Net has taken in general. I have worked in a few environments where most of the devs and projects themselves feel stuck in concrete. I've left a couple places like that in the past few years just because they are painful environments to work in.

I couldn't even tell you how to do certain things in the VS gui at this point... I've got Rider and VS installed only because Rider is nicer for refactoring and I've had to fix VS launch issues a couple times (VS backend, vite/react frontent).

Prior to .Net core I had one foot out the door, mostly towards Node... Now, I'm fine with either/both... though all my shell scripting is now with Deno/TS.

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

#119

Post by tracker1 »

jve wrote: post #70
frank_nitti wrote: post #43

Earlier quoted context omitted.

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

Thanks for making me feel like a 10x dev :) Anyways, I work with .NET Framework and .NET. Being a developer is a joy where you can learn daily new tricks and satisfy your curiosity. So to me this reads so alien that people fail to learn new tricks within .NET world. For me it's like a stream of amazement: Ohh, this is so much better with new language features. Ohh, this code is so much more clean. Woa, logging is so…

Funny... I actually kind of hate ILogger... at least the output implementations I've seen. I really like line-delimited JSON for standard logging with a pretty-printed version for local dev. With say a node project, I will usually attach a few bits of context as well as a details object with the simple log message... this is easy enough to ship to another system, or say with AWS, the built in logging platform handles it brilliantly.

I haven't seen a good logger implementation for .Net that does a similar good job without a bunch of byzantine configurations.

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

#120

Post by tracker1 »

smt88 wrote: post #52
N_Lens wrote: post #3

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

.NET churns less than any other major stack. Every upgrade since Core 2 (released in 2017) has been minimally painful or, more recently, painless.

Similar 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.
Post reply on HN