.net core short life cycle mitigation

Viewed 389

Context: We are developing new web applications for medical devices, these devices are maintained in field(customer premise) for 10 years. On these devices we can do updates for Microsoft windows OS patches or even updating a .net core runtime is also ok.

Problem: If we release an application with .Net core 3.1 LTS this year, post Dec 2022(EOL for .Net core 3.1), we need to again release and deploy the application in field which is a very costly affair. The cost here is on integrating, retesting and deploying the application with new .net core runtime( cost is not on updating/installing .Net core runtime).

We are using the rollforward policy - latestpatch link . This allows application to use the latest installed patch (like .Net core 3.1.8). Using any other Rollforward policy will risk breaking the application in field.

Any help on how to deal with this limitation of .Net core, rolling back to .Net 4.7.2/.Net 4.8 for WebAPI's is one option but its like going back and not getting advantage of latest technology stack.

1 Answers

I'm afraid there is currently no middle ground as having more features also means breaking changes in new .NET (Core). So I'd say this is more of business decision, I don't believe there is a sane workaround to always updating to LTS .NET Core as long as you are exposing a public surface such as web API unless you disregard security completely. .NET Framework, on the other hand, is stable, and is here to stay.

Remember also that finding developers to hire, libraries and internet resources (articles, documentation) will get harder and harder over time as you stay with .NET Framework, but such is the fate of the kind of software you develop.

Maybe Microsoft will one day make a longer-term LTS version of .NET to convince more conservative users to migrate, perhaps it could even be .NET 6, but until then, .NET Framework is the way to go.

Perhaps being able to see the difference between ASP.NET and ASP.NET Core now can help you define your architecture so that future migration - if any - is feasible (i.e. not a complete rewrite). ASP.NET Core generally builds on more modern principles to software design so you would be doing yourself a service anyway.

Related