7 ms·

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 c

by kcb 4y ago

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.

colejohnson66 4y ago
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-publish https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-p...
- Arnavion 4y ago
  Bundling the framework doesn't solve the problem of said framework being old and unsupported because it wasn't LTS.
  - Jwarder 4y ago
    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/runtime-patch-selection https://learn.microsoft.com/en-us/dotnet/core/deploying/runt...
    - foepys 4y ago
      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.
      - easton 4y ago
        .NET Core security patches aren't pushed via Windows Update, only .NET Framework (since it's built into Windows). Unless something changed recently?
        vel0city 4y ago
        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.
        pjmlp 4y ago
        .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.
        seritools 4y ago
        If "Microsoft Update" is enabled in the Windows Update settings, you do get .NET Core updates: https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/ https://devblogs.microsoft.com/dotnet/net-core-updates-comin...
        easton 4y ago
        News to me! I always deploy .NET 5/6 stuff on Linux, explains why I'm out of the loop. Thanks!
    - AlfeG 4y ago
      It's same issue as deploying containers.
simplotek 4y ago
> 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.
- to11mtm 4y ago
  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'.
  - TrueSlacker0 4y ago
    And web forms to core was/is terrible.
    - AlfeG 4y ago
      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.
dangus 4y ago
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.
- kcb 4y ago
  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.
  - TillE 4y ago
    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.
  - phillipcarter 4y ago
    The answer is to fix your processes, not demand Microsoft accommodate them. The lifecycles are already plenty long.
    - to11mtm 4y ago
      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.
      - phillipcarter 4y ago
        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?
AtNightWeCode 4y ago
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.
- kcb 4y ago
  .NET Standard is for libraries only.
  - AtNightWeCode 4y ago
    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.
    - eterm 4y ago
      Binding redirects should solve that issue.
      - AtNightWeCode 4y ago
        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.
    - voxic11 4y ago
      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/#the-fix-if-youre-using-net-framework https://nickcraver.com/blog/2020/02/11/binding-redirects/#th...
phillipcarter 4y ago
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.
- deleted 4y ago
  [deleted]
- kasajian 4y ago
  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.
- chiph 4y ago
  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.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
paxys 4y ago
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.
- kcb 4y ago
  It's not 3 years of support though, if you ship mid next year it's 1.5 with no alternative to choose.
  - paxys 4y ago
    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.
vraylle 4y ago
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.
- pathartl 4y ago
  .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.
  - osigurdson 4y ago
    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.
  - TrueSlacker0 4y ago
    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.

by kcb 4y ago

colejohnson66 4y ago

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-publish https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-p...

Arnavion 4y ago
Bundling the framework doesn't solve the problem of said framework being old and unsupported because it wasn't LTS.
- Jwarder 4y ago
  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/runtime-patch-selection https://learn.microsoft.com/en-us/dotnet/core/deploying/runt...
  - foepys 4y ago
    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.
    - easton 4y ago
      .NET Core security patches aren't pushed via Windows Update, only .NET Framework (since it's built into Windows). Unless something changed recently?
      - vel0city 4y ago
        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.
        pjmlp 4y ago
        .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.
      - seritools 4y ago
        If "Microsoft Update" is enabled in the Windows Update settings, you do get .NET Core updates: https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/ https://devblogs.microsoft.com/dotnet/net-core-updates-comin...
        easton 4y ago
        News to me! I always deploy .NET 5/6 stuff on Linux, explains why I'm out of the loop. Thanks!
  - AlfeG 4y ago
    It's same issue as deploying containers.

simplotek 4y ago

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

to11mtm 4y ago
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'.
- TrueSlacker0 4y ago
  And web forms to core was/is terrible.
  - AlfeG 4y ago
    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.

dangus 4y ago

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.

kcb 4y ago
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.
- TillE 4y ago
  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.
- phillipcarter 4y ago
  The answer is to fix your processes, not demand Microsoft accommodate them. The lifecycles are already plenty long.
  - to11mtm 4y ago
    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.
    - phillipcarter 4y ago
      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?

AtNightWeCode 4y ago

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.

kcb 4y ago
.NET Standard is for libraries only.
- AtNightWeCode 4y ago
  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.
  - eterm 4y ago
    Binding redirects should solve that issue.
    - AtNightWeCode 4y ago
      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.
  - voxic11 4y ago
    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/#the-fix-if-youre-using-net-framework https://nickcraver.com/blog/2020/02/11/binding-redirects/#th...

phillipcarter 4y ago

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.

deleted 4y ago
[deleted]
kasajian 4y ago
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.
chiph 4y ago
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.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

paxys 4y ago

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.

kcb 4y ago
It's not 3 years of support though, if you ship mid next year it's 1.5 with no alternative to choose.
- paxys 4y ago
  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.

vraylle 4y ago

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.

pathartl 4y ago
.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.
- osigurdson 4y ago
  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.
- TrueSlacker0 4y ago
  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.