Hacker News Reader

Comment by kcb | Hacker News Reader

They really need to extend the support time for their LTS releases. Sure, if you're developing a SaaS you can stay on top of .NET versions but it's definitely causing friction for enterprise and slow moving regulated software. .NET Framework 4.5.2 was supported for 8 years in comparison.

We're about to start a project with those limitations and there really is no good choice now that .NET 6 is already a year through it's lifecycle.

View on HN

If, when publishing your app, you choose the "self-contained" mode (as opposed to "framework dependent")[a], the runtime will be bundled with your program into the executable. Then you don't need to worry about updating your client's OS. My work is using it for deployment to Linux, and it works great.

[a]: Pass the `--sc true` option to `dotnet publish`: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-p...

Bundling the framework doesn't solve the problem of said framework being old and unsupported because it wasn't LTS.

Seems like it makes the problem worse because you are then tied to a specific version at time of publishing and need to republish to get any framework patches.

https://learn.microsoft.com/en-us/dotnet/core/deploying/runt...

Indeed. Microsoft identified this as a problem as well and pushes .NET security patches via Windows Update nowadays. When using self-contained apps, you won't get these patches.

.NET Core security patches aren't pushed via Windows Update, only .NET Framework (since it's built into Windows). Unless something changed recently?

You missed how there effectively isn't a .NET Core/.NET Framework delination anymore. It is just .NET, and .NET gets security patches from Windows Update.

.NET Core got renamed into .NET as of .NET 5, and it is still quite relevant to make a difference, plenty of people still don't get it.

If "Microsoft Update" is enabled in the Windows Update settings, you do get .NET Core updates: https://devblogs.microsoft.com/dotnet/net-core-updates-comin...

News to me! I always deploy .NET 5/6 stuff on Linux, explains why I'm out of the loop. Thanks!

It's same issue as deploying containers.

> Sure, if you're developing a SaaS you can stay on top of .NET versions but it's definitely causing friction for enterprise and slow moving regulated software.

You have a point, but I'd call out that migrating to newer releases can and often is trouble-free.

A couple of months ago I worked on a .NET Core 2 web service that was put on cold storage for a few years, and all it took to migrate it to .NET Core 6 was a few version number bumps and a rebuilding the project.

YMMV of course, but LTS shelf life might not be a deal breaker.

You may have gotten particularly lucky.

I say particularly, because Core2->Core3.1 was a fairly painful change for some.

I'd say the 66% worst case is 'you also have to add some compat flags and stories to properly resolve the compat flags'.

And web forms to core was/is terrible.

It took almost two years of development to do this conversions in out project... but in my case heavy lift of move from webforms to mvc were already done, so it a bit easier.

What limitations are involved? I’ve never really understood why 3 years is unacceptable or intractable. In nearly every case the real issue is that nobody wants to fix broken internal processes that prevent people from upgrading once a decade.

It has everything to do with creating a product that you sell to a customer who installs it on premise within their environment, and their IT policies require that software be supported for a certain period of time. Even if you're good at changing their mind some of the time, it's not going to happen every time, so you're basically turning away potential customers, which some people aren't willing to do.

This is why it's much better to move away from the shrink-wrap model of delivering software and focus on SaaS only solutions.

It's not always that the internal process is broken - it's that sometimes it takes a very long time to get a new release approved for use (even if it's an upgrade to one that the customer has already been using). Sometimes it's the customer's process that is slow (big enterprise culture), sometimes there are one or more third parties involved. Sometimes it's both.

Many years ago I wrote software for a medical device. Before we could sell the device we needed to get it tested by Underwriters Laboratories to ensure it was safe (wouldn't shock people) and could be cleaned by hospital staff without damage. We also had to do the process to get the CE mark for it so it could be sold in the EU. And of course the FDA needed to approve it. It took nearly a year for all this, before we could offer it for sale and start marketing it.

So there's a third of the LTS lifetime consumed, right there.

There isn't any functional difference between a 3 year or 5 year or 8 year support cycle. The only two development modes for a service are – build once and maintain occasionally, or build once and leave untouched forever. Those in the first set will be fine with 3 years of support. Those in the second will always ask for more time no matter what the deadline is.

It's not 3 years of support though, if you ship mid next year it's 1.5 with no alternative to choose.

There will be a new LTS version available for 1 out of those 1.5 years. Plenty of time to upgrade. Plus, the advantage of shorter release cycles is that there are fewer breaking changes from one version to next. As long as there is decent test coverage it could be as simple as updating the build target in your CI tooling and calling it a day.

Slow moving orgs with brittle release processes are going to miss support deadlines anyway, it doesn’t matter if they arrive sooner or later.

Until the date hits them in the face there’s no urgency.

Unfortunately in some industries continuous delivery is literally illegal. Anyway there's a real issue with their current schedules. Let's say you're developing software some time in the middle of next year. There's effectively no LTS release available at all.

We're not talking about "continuous delivery", this is just having a plan to ship updates every two years, on a well defined schedule. If you can't manage that organizationally, there are deeper problems.

It's not really Microsoft's job to work around your awkward requirements. Everything is open source, you can ship patches for .NET 6 yourself if you really want to.

The answer is to fix your processes, not demand Microsoft accommodate them. The lifecycles are already plenty long.

My issue is the cadences are difficult to work with.

Microsoft's general-ish LTS for .NET is 2 years. We also only seem to get a new release every 2 years. It's hard to handle breaking changes between two versions quickly.

LTS for .NET is 3 years, not two. There's a new LTS every 2 years, so you get a full year to move from LTS -> LTS if you need to.

What kind of breaking changes have been hard to handle?

None so far

Any way you look at it 3 years is pretty low for industry standard LTS lifecycles. Besides the .NET Framework comparison Java LTS is 5-8 years.

Node (used at least as much as .NET and Java in enterprise) has a 3 year LTS cycle, so I don't know if it's really low for an industry standard.

    Node (used at least as much as .NET and Java in enterprise) has a 3 year LTS cycle

I'm gonna need a citation on that. From what I've seen, what enterprises have done any node adoption have fled it like rats fleeing a sinking ship because of all the problems it's had over the past half decade. To the point that shops I've worked with are moving back to Java.

It is quite clear on node's documentation.

https://github.com/nodejs/release#release-schedule

Pretty sure they are asking for a citation on the usage and not on the LTS schedule.

I've seen the opposite.

I agree that LTS should last longer. They made it easier to upgrade between versions though. Perhaps won't help you if you use .NET in patient critical medtech for instance (in EU).

Biggest problem for us is .NET Standard. I don't even understand how it could work on a theoretical level. Maybe it could work if there was no dependencies.

.NET Standard is for libraries only.

I know what it is. It is just broken. App A uses a .NET Standard lib B that needs lib C. Since the purpose of lib B is to be as compliant as possible it targets some .NET Standard 1.x. Lib C is used already by the app. And now, dependency hell.

Binding redirects should solve that issue.

Sometimes. But most .NET devs don't even know what a binding redirect is. They will also break on a regular basis when packages are updated.

Edit: The bindings that is. Maybe the devs too.

I guess I am missing something, why does this cause dependency hell? I guess microsoft is basically recommending against targeting netstandard now anyways so there must be some problem with it. But I don't think I have run into any problems with the situation you described.

edit: Ok I see, it seems in that scenario loading the correct assembly is more difficult on dotnet framework and usually requires binding redirects to be specified. On dotnet core/.NET 5+ there are no issues though, which is why I haven't experienced this problem myself.

https://nickcraver.com/blog/2020/02/11/binding-redirects/#th...

It has never really worked between different .NET versions. Nothing new with .NET 5/6/7.

We pretty much banned .NET Standard for any in-house dev.

We're in the process of migration a large MVC application from Framework 4.8 to .NET 6. It's been....painful. Hopefully at least for a while updating to new LTS versions will be less so.

.NET Core 2 to 3 definitely had this feeling that their vision for the framework wasn't complete. Going from 5 -> 6 -> is pretty painless.

We are also preparing for a move from .NET Framework 4.7.2 to .NET 6/7. It's going to be quite the project.

We did that last year on a 3 million line / 500 person-year investment application. Quite challenging as everything from app domains to remoting, to call contexts and other unsupported things were being used. It was definitely worth it for performance alone as we were also using Mono to run on Linux.

I am moving a personal project with ~50k loc and it has turned into a rewrite of about 2/3 of it. Not fun, but on the plus side the app runs A LOT faster now. So much faster that even non tech people that use it noticed the difference.

Reply on news.ycombinator.com