.NET has been evolving rapidly in the last few years delivering new features quite fast, new improvements in C# and open source libraries to enhanc...
For further actions, you may consider blocking this person and/or reporting abuse
I think that the main problem is that Microsoft has this weird cultural taboo against telling companies they should think about upgrading. Like, they have enterprise customers they don't want to tick off, so they're terrified of inheriting Google's reputation for constantly killing projects, so they say, "Don't worry--we're committed to continuing to support Internet Explorer for the life of the operating system" or "Don't worry--all of your .NET Framework projects will be supported for the life of the operating system" or "[awkward silence in the direction of projects like WCF that they want to kill silently by just not including them in Core] ..."
Of course the quiet part that they don't say is, "This will go away eventually! Stop building new projects in .NET 4! Stop building new projects that require Internet Explorer's ADFS auth! Stop building new projects in ASP.NET WebForms!" Any reasonable person should be able to read the quiet part between the lines, but management is strongly incentivized to stick their fingers in their ears rather than invest in employee training or (in the case of IE/ADFS) re-engineering and will go on building new software right up until Microsoft announces the actual end date.
But the thing is: it's kind of like how a vampire can't enter your home without your permission. Microsoft should suck less blood and be more transparent about their support cycle, but regardless, companies should commit to always releasing new software in the current version and keeping older projects up to date in regular, incremental changes over time so they don't have to be afraid of EOL dates instead of inviting the vampire's half-truths. Technical debt charges interest and it's a mistake to think you can just leave a piece of software on the shelf and not put effort into maintaining it.
I agree with you on some topics.
Enterprise and traditional companies are waiting for a guide and best practices for Microsoft and currently there is not a culture of upgrading software constantly.
Many companies prefer to buy tools and third party components to save time writing code instead of training developers about best practices, DevOps culture and modern solutions. This is a big mistake.
I think that there's quite a bit of confusion in the framework naming schemes as well:
.NET Framework 6.0
.NET Core 3.1
ASP.NET Core 6.0
Seems like they should have started the Core frameworks at 10.0
.NET Framework is not going to move foreward to version 6.0. It will have more minior releases like 4.8.5 etc..
I think in next year we will see more and more projects in .NET Core and the version will make more sense.
The actual name of the framework is .NET Framework 6, though. They dropped the word "Core" from the framework name officially after Core 3, so .NET Framework 5, .NET Framework 6 etc are successors to .NET Core 3.
tswiftma is right that it is an incredibly and unnecessarily confusing naming convention.
Agree with this. the name are confusing but the current name is .NET 6 not .NET Framework 6. I know this is a simple word but this is the different between one and another.
Oh shoot you're right sorry
Yeap. I do feel they are moving in such a fast pace that is really hard to keep up with.
The team I work is small and we focus on delivering business requirements. We came from the .Net Framework world, so we also are not used to have to upgrade the framework version so often. We developed some APIs a few years ago using Core 3.1 and still haven't upgraded them to .Net 6 because we simply couldn't find time to do that.
It's not that it's something hard to do per se, but it requires to change the deployment pipeline as well (which is something nobody wants to touch 😅).
Furthermore, it's difficult to explain the reasons to upgrade the framework, so that's simply never entering the sprint.
In order to not commit the same mistakes again, later when we created another API, we choose .Net 5... which, thinking now, is actually worst, because it's already deprecated 🤦.
I don't want to be misunderstood here, I love that Microsoft is investing so much work on the framework, I love C#, and the performance boost they are providing is fantastic. But I also don't know how to address the issue of keeping upgrading already existing solutions.
Is it a team problem? Are we too used to FX? Do we need to change the way we think? I don't know, I truly don't.
The problem of not updating to the newest version is that the framework keeps changing. Newer versions will be released once a year. I feel that the more time we delay upgrading, the more trouble we will have when we finally do that... Which makes me wonder whether a functional app actually should be upgraded until there's a real requirement to do so.
I don't know, I may be wrong, but I just constantly feel that we simply can't compete with such pace of releases, and that we are just being left behind. And I have no idea about how to handle that 🤷🏻♂️.
you included all my concerns in your comment. it's very common to use the last version of the framework since we want to use the last template and new C# features but sometimes it is a bad choice when the version is non-LTS you have to be careful and update with the new LTS version is released. Well we need to include in our culture upgrade our framework constantly.
I Think Microsoft by far has the most stable frameworks out there , that's why it's kinda used for important and big projects ,which raises the question why having so much versions ? it can only confuse people about the future of the framework and which version is stable enough to use, personally i think .NET Core 3.1 is pretty great but it will not be supported by December 13, 2022.
Yes I think the same, the framework is very stable the only issue is to perform upgrades constantly, specially when you are not using a LTS version.