-2

I want to start developing a long-life ERP system to a customer. now on paper I would chose to develop it using .NET core 6.0 with SQL Server. But one of the main drawbacks which the customer did not agree on, is the short support life cycle for .NET core framework. where each 3 years a new version of the .NET core will be released, and the previous versions will stop receiving security updates, which can leave our project open to vulnerabilities.

so, what other .NET frameworks we can chose if we want: -

  1. To use the MVC framework which we already have experience in.
  2. have a long-life support?

Can anyone help me with this issue I am facing with the client? we are going to host our application on windows anyway.

Thanks

microsoftdeveloperdesigner
  • 121

2 Answers2

1

The .NET technology stack has been in a state of transition from long periods between releases, to more frequent, incremental releases. When faced with this situation, you have a number of considerations to account for:

  • How long will the old version of the framework be supported? (e.g., .NET Framework 4.x).
  • Are new libraries going to be developed for the old framework?
    • Are people maintaining the old libraries for the old framework?
  • How difficult is it to keep updating the framework?
    • Impact to application code.
    • Impact to build and deployment tools.

Generally you want a balance of stability, ease of upgrades, long term support, and frequency of new features. You will need to do some analysis to verify the fears your client has. Given more information, they might change their minds and opt for .NET 6+.

Then again, you also need to understand the system requirements the client is working with in their own ecosystem. If this application will be deployed on the client's infrastructure, they might have their own enterprise policies for technology support. The client might have old, mission-critical applications that are difficult or impossible to upgrade without "the big rewrite". I would certainly question their framework recommendation if this application is deployed on your company's infrastructure. You will be handling the upgrades every three years.

Overall, you will need to research the old and new frameworks to balance the benefits and drawbacks of using either one. Additionally, you will need to understand your client's technological needs because IT systems do not exist on their own. They frequently live alongside other solutions built at various times with differing technology stacks.

Just be sure to plainly note the disadvantages and costs associated with choosing an older framework or technology stack, which includes a timeline for support before "the big rewrite" is necessary for the new thing you are going to build.

Greg Burghardt
  • 45,304
0

If you start right now you can also use the .net 8 preview version. It will be released in November, so if your production use starts after nov 2023, it should be fine.

We use .net in production and we upgrade to every version. I think we went from .net core 2 to 2.1 to 2.2 to 3.0 to 3.1 to 5, to 6 and now we are on .net 7. Every time it was a bit of work but this is an ongoing project so some maintenance is to be expected.

So yeah, if you want fewer updates go with LTS and only upgrade to the next LTS version. As they come out every 2 years, you have a whole year to upgrade from one to the next one.

Note that also customers do not always like stability. "Works with Windows XP" might have been cool back then but the real requirement is "works with todays windows and the version prior" or so. Nearly all requirements shift and an application that is not maintained and updated will loose its appeal in a few years time.

Constant app maintenance is a recipe for success and upping the .net version from 6 to 7 to 8 can be part of that. If you deliver your application in a container, your customer does not even need to care about the .net version.

So a summary: If you want a long support period, choose .net LTS with 3 years support. That is the long support period. The short one is 1.5 years.

Edit: On top of that: You should strive to update your app much more often than every 2-3 years. For one because maybe you created a security issue, but maybe for other reasons or limitation. So ideally you arrange a regular update window and some of the updates include updated dependencies (like a .net version jump) For example, I had an application where I displayed a sum of filesizes in an int32. Broke after 7 years and 2GB of files and suddenly they wanted a fix. Would have been better with more frequent updates and internal monitoring of limits.

DasKrümelmonster
  • 410