3 ms·
The bigger issue for me will be the way that these kinds of things tend to split communities. It doesn't do big enterprise devs much good if we have a lot of c
by corpdronejuly 5y ago
The bigger issue for me will be the way that these kinds of things tend to split communities.
It doesn't do big enterprise devs much good if we have a lot of cool new features if there's no path towards using them in our 20 year old legacy applications that keep the business running.
- giobox 5y agoIf you are a server side web app, the migration process from legacy net Framework app to net 5/6 has gotten _a lot_ easier in past few years. The biggest barrier for most in my experience has been getting through the project file (*.csproj) changes needed. Even today, there is still no fully automated way to do it. Thankfully, after ~4 years of community complaints, Microsoft finally aquiessed and made a CLI tool that does about 80 percent of that work: https://github.com/dotnet/upgrade-assistant https://github.com/dotnet/upgrade-assistant Before the release of this tool, you had to rely on community made tools/guides or just rewrite the project file by hand to the new format. I inherited a project with over 600 large net4x csproj files - prior to this tool Microsoft's official stance was "rewrite them by hand". This goes down like a cup of cold sick at many Enterprise software shops with hundreds or thousands of project files to update. I still think the upgrade process needs some more polish/wizards in the VS UI, for junior developers especially, but it's gotten much better. The vast majority of important third party dependencies are all net5 ready now in my experience now, so often just replacing the csproj file and setting target framework to net5 is enough. If you have a legacy WinForms/GUI app however and want full cross-platform benefits of net5... cost to move to modern UI framework can be significant. CLI apps/web apps are by far the easiest to port to net5.
- coldacid 5y agoI don't think moving from legacy .NET Framework to modern .NET is the issue here. I have a web API application that has moved from .NET Framework 4.5 to .NET Core to .NET 5 and just updating for the newer framework has been the simplest part of each upgrade. The real problems come with the changes to the ASP.NET libraries and the changed expectations regarding how such applications are built. This push towards the "minimal APIs" for .NET 6 may be great for trivial or just-bigger-than-trivial projects but it starts falling apart whenever you have something more complex. The setup class system of older ASP.NET editions, while decried as boilerplate, actually makes it easier to manage the configuration and structure of larger web app projects. I don't expect to ever move any of the ASP.NET projects that I work on to use these minimal APIs, and I expect that any new projects will be quickly adapted away from them out of the new project templates out of Microsoft.