Upgrade from .NET Framework to .NET 5 can be hard. New official tool may help... slightly Microsoft has previewed a new upgrade assistant to help developers port .NET Framework applications to .NET 5.0, but it is a long way from a complete solution. When Microsoft forked the .NET Framework to become the open source .NET Core (now just known as .NET) it created a problem: no easy upgrade path for existing .NET …
Depends on what you mean with "DLL hell". I've always understood "DLL hell" to be the phenomenon where poor versioning of shared libraries can break an existing app in hard-to-diagnose ways. For example, an app could randomly decide to upgrade or uninstall a DLL, and break some other unrelated app that relied on it.
This is not an instance of that - .NET versioning is much better, so that existing .NET Framework apps will continue working just fine alongside new-style .NET Core apps.
This is more like an instance of, a new major version of your favorite framework is out, and it's not backwards compatible: you can keep using the old version and miss on the new features, or you can get the new features by investing significant work.
This situation happens all the time, not just in .NET - actually, .NET so far has been reasonably good at being backwards compatible compared to e.g. web development, where it seems to me that, if you want to stay up-to-date, you generally have to do major upgrade work every few months, and redo the app from scratch every couple of years.
"This is more like an instance of, a new major version of your favorite framework is out, and it's not backwards compatible: you can keep using the old version and miss on the new features, or you can get the new features by investing significant work."
I don't think you need to cast that as a simile. This is the EXACT dictionary definition of what you just listed.
OK folks, remember the rules.
No complaining.
This is job security. This is what will keep you employed for the next cycle of your career. And the best part is that even if it's not, your employer will have to pick an alternative which you'll reskill into and redevelop everything - which will still keep you employed!
So no complaining. Well, not here, obviously. You can complain to your management. They need to know it's a problem, but not an insurmountable one. A significant change. The kind that can't easily be handled by offshoring either, as knowledge of the existing codebase is critical to the success of the project.
Yes, if you play this well, it's basically an assurance of future beer tokens... and what's not to like about that? ;-)
"Everything looked good until we loaded and attempted to build the result. "Consider app.config remapping of assembly "Microsoft.Data.Services.Client … Choosing "Microsoft.Data.Services.Client, Version=5.8.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" arbitrarily," said Visual Studio."
This happens every time you update a package, Visual Studio will even do it for you if you double click the message. I'm guessing the author doesn't have a lot of .NET development experience?
Also HttpUtility is now in a new assembly System.Web.HttpUtility.dll. The tool probably should have added it automatically, but it would be trivial to add.
I'm not saying the tool is great (I've used it and it has definite shortcomings, I'd even say it's not really finished). Just that the methodology used was flawed. Next time find someone who is a .NET expert if you're going to evaluate .NET conversion tools.
Did you try upgrading the same asp.net MVC project using the AWS porting assistant for .NET? The porting assistant has gone through multiple iterations, the latest version does a fair bit of code updating for you. On one relatively simple app I tried, the updated project built and ran after changing one line of code.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
