-3

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
  • 11
  • 2
  • There are two votes to close this question as being off-topic, because it is asking for a tool or framework recommendation. Before we get the last close-vote, we might want to consider some general advice about *how* to decide given this situation. – Greg Burghardt Apr 13 '23 at 15:59
  • @Greg Burghardt but if i cannot ask architecture questions on this forum, then which forum i should use? there is already a tag for architecure .. am i missing something ? – microsoftdeveloperdesigner Apr 13 '23 at 16:01
  • The tags on the question don't determine if this is an architecture question. The perceived intent of the question title and body text is the bigger consideration. I personally do not think this is a "tool recommendation" question. I believe this can be answered objectively with a more generalized conceptual response. – Greg Burghardt Apr 13 '23 at 16:03
  • 1
    I don't know how to feel about this question. On one side, you are taking monumental task of develping "long-life ERP system". On other, you are asking question that demonstrates you have little understanding of .NET ecosystem and history of last few years. .NET Framework is dead. .NET Core only has limited support time, because it is in active development and MS won't support versions that have been long rendered obsolete with new ones. .NET Framework is no longer develped, so MS doesn't expect there to be many new security issues. – Euphoric Apr 13 '23 at 16:09
  • @Euphoric so if you were in my place , then you would go for .net core 6.0 and keep updating it each 3 years? to stay secured with MS updates ? second question, is .net 4.8.1 is really dead ? as seems it will stay supported for long time @ https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework – microsoftdeveloperdesigner Apr 13 '23 at 16:12
  • I would not "update it every 3 years". I would update it every time new version comes out. And yes, .NET Framework is dead. Version 4.8 is 3 years old (4.8.1 is just minor patch version). In those 3 years, .NET Core has seen massive improvements in support (Linux, ARM), performance, features, libraries and everything else. If you use Framework, your system will become outdated legacy the moment you write first line of code. – Euphoric Apr 13 '23 at 16:27
  • @Euphoricyou mentioned `I would not "update it every 3 years".` but every 3 years we get a new .net core version. second question, what do you exactly mean by ` If you use Framework, your system will become outdated legacy the moment you write first line of code. `? – microsoftdeveloperdesigner Apr 13 '23 at 16:34
  • https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ – Ben Cottrell Apr 13 '23 at 16:57
  • You might also want to consider that .NET is a whole development ecosystem - it may still be receiving critical updates for now, but it will never support a newer version of the C# language, so you will be missing out on newer language features and stuck with C# 7.0. The wider .NET community who maintain popular 3rd-party libraries and tools are already moving away from .NET Framework, so that will drastically reduce the benefit of using the .NET ecosystem. Not to mention that when 4.x does eventually retire it'll be a far greater effort to move to a supported version. – Ben Cottrell Apr 13 '23 at 17:08
  • @BenCottrell Thanks for the reply .so you do not see any issues of the short .net core support life cycle? so the customer will have to pay atleast each 3 years for the upgrade ? – microsoftdeveloperdesigner Apr 13 '23 at 17:29
  • I attempted a conceptual answer that could be applied to .NET or any technology stack facing a similar situation. – Greg Burghardt Apr 13 '23 at 17:33
  • @microsoftdeveloperdesigner 3 years is an extremely long time in software. However I see far more issues and cost when migrating from .NET 4.8 (which is a major re-platforming exercise) compared with simply bumping the version from .NET 6/7. Modern .NET "Core" is a fundamental ground-up rewrite of the entire platform with major breaking changes, whereas new releases for modern .NET are essentially small evolutionary steps where breaking changes are minimal and in most cases may not affect you at all, so the cost of moving to a new version is likely to be small. – Ben Cottrell Apr 13 '23 at 21:54

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
  • 34,276
  • 8
  • 63
  • 114
  • thanks for the reply. but if we chose .NET core 6.0 , then on November 2024 (in 1.5 year) we will need to upgrade it to .NET 8.0 else we will not receive any security updates. and if there is a vulnerability inside .NET 6.0 we will face this vulnerability. this is the main customer concern ..they are looking for security issues on unsupported versions (which will be the case for .NET core 6.0 on November 2024 unlike .NET 4.8.1 which will still receive security updates by that time.).. did you get my point ? – microsoftdeveloperdesigner Apr 13 '23 at 17:38
  • also the system is going to be deployed on the customer infrastructure – microsoftdeveloperdesigner Apr 13 '23 at 17:41
  • I get your point, but you aren't quite understanding my answer. You need to make a judgement call: update frequently to get security patches, or update less frequently to get security patches until .NET 4.8 reaches end-of-life (and then you are faced with "the big rewrite"). You need to understand that there has been a sea-change in how Microsoft manages the .NET framework. Gone are the days when you could install .NET framework and only worry about major updates every 10 years. Bear in mind that framework updates now are much less painful than going from .NET 4.x to .NET Core or 6+. – Greg Burghardt Apr 13 '23 at 17:53
  • yes got your point `Gone are the days when you could install .NET framework and only worry about major updates every 10 years`.. so would you leave a .net core project on production servers even if it is out of support? or you always seek to upgrade to the latest version? – microsoftdeveloperdesigner Apr 13 '23 at 18:05
  • Tell your customer that you *recommend* updates every 3 (?) months but they need updates at least every 2 years for security. Generally speaking it is not enough that the framework is under support, for good security you need to support your app as well. – DasKrümelmonster Apr 13 '23 at 19:13
  • @DasKrümelmonster Thanks for the update, of course i will update the code if there are functional issues or new requirements. my question is about the .net framework. if we chose .net core 6.0 then it is a must to update the project on November 2024 otherwise our .net might have security holes... this is my main question/issue – microsoftdeveloperdesigner Apr 14 '23 at 10:57
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
  • 363
  • 1
  • 4
  • thanks for the reply. the system will be deployed on the customer infrastructure, so that why they are worried about old .NET core versions not receiving updates and at the same time they are worry about the price for the upgrade each 3 years.. so that why i am comapring 4.8.1 with .net core 6.0 – microsoftdeveloperdesigner Apr 13 '23 at 18:08
  • Just to get this right ... if they want an update only every 3 years ... and they find a security issue (in your code) 3 months after the app is installed the are happy to wait 2.75 years for the fix? – DasKrümelmonster Apr 13 '23 at 19:16
  • not sure how we should deal with this then? so we need to update the code every time a new minor release of the current .net version (6.0 or 7.0 or 8.0 ) get available ? do we need in this case update the project program.cs files and all the referecnes ? – microsoftdeveloperdesigner Apr 13 '23 at 19:43
  • also if they found a security issue in my code i can update my code, i am taking about security issues if we use .net version that is no longer supported by microsoft.. since we will not get security updates after the .net version is no longet supported – microsoftdeveloperdesigner Apr 13 '23 at 20:45
  • I'd try to arrange for a regular update window (like every three months) and always deliver the update with the up-to-date .net LTS version. You can just base your dockerfile on `6.0-bullseye-slim` and you get 6.0.x – DasKrümelmonster Apr 14 '23 at 11:19
  • But based on my reading, updating the csproj file for the TargetFramework will only be needed if we change the whole .net version let say from 6.0 to 8.0 . but any minor updates for the .net 6.0 (6.0.X) do not require updating the csproj file.. – microsoftdeveloperdesigner Apr 14 '23 at 11:25
  • Yes, I would just not make a big deal out of it. Your customer (ideally) gets regular updates and sometimes this includes a .net update from 6.0.7 to 6.0.10 and another update may contain a .net update to .net 8 – DasKrümelmonster Apr 14 '23 at 11:31
  • the minor updates from 6.0.07 to 6.0.10 will already be part of windows update.. so i do not have to worry about this update.. and this update will not require updating the csproj file targetframeowrk.. after November 2024 we will evalute the benefits of upgrading to 8.0 which will require updating the code and at least the csproj file. – microsoftdeveloperdesigner Apr 14 '23 at 11:48