Microsoft .NET to .NET Core Upgrade Assistant #5625
-
Microsoft .NET Upgrade Assistant This is not the "Magic Wizard" we may see one day but anyone looking to upgrade this tool helps give steps on what to do to make the transition to .NET Core I found today I thought I would share. Not sure if the Upgrade Assistant has been discussed as an option for helping in the event DNN Community decides to go to .NET Core?
|
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 5 replies
-
unfortunately, DNN is a .Net WebForms application which is not supported by this tool. |
Beta Was this translation helpful? Give feedback.
-
As @sleupold the real issue is that System.Web, which is an underpinning requirement for DNN doesn't exist in .NET Core. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the feedback I will pass it along! I will see what the plan is for the migration tool and if there is something cooking up for a future release that may help us here. I asked if a plan for this type of migration fits the scope of the project and if so I will link the issue(s) related inside the github repo located here: |
Beta Was this translation helpful? Give feedback.
-
@thabaum you seem to have a lot of frustrations with a lot of different things here in this very long post. DNN is a mature platform that was built from the ground up on webforms, it also supports mvc and webapi. There are templates available for many different frontend technologies and it does not enforce anything on the developers and supports a very very wide variety of development patterns. Most of those that have been using the platform for a long time appreciate this. Octane was started with some of the same overall ideas as DNN but starting from scratch on today's new stacks. Maybe that would be a good solution for you if find that the benefits of .netCore outweigh the benefits of DNN ? .NetFramework is not out of support and won`t be for quite some time. .Net Core on the other hand has very very short LTS cycles, it is a much faster-moving target. If we drop support for .NetFramework quicker than we need to, it would kill almost all 3rd party extensions and the platform with it. DNN being open-source, nobody is getting paid to work on this and migrating to .Net Core is not a priority or a focus for those spending their free time working on and with the platform. Most need to support older extensions, keep maintaining older sites alive and secure, etc. That being said, some great efforts were put in place by such awesome individuals to get us part of our codebase on .netStandard and having dependency injection available in most places. So we are not refusing any efforts to get us closer to .netCore either but not at the cost of killing 3rd party extensions/themes, etc. May I ask why you want .NetCore so much? There are only a handful of good reasons to have to migrate to .NetCore
Well, 1st, maybe development is not your thing :) What is flagship today may very well be obsolete in a decade. 10 years ago I was the biggest javascript hater and loved webforms, telerik controls and using an insane amount of dependencies. A few years after I just wanted to kill webforms stuff everywhere and do React with javascript. A few years later now I do more typescript than anything and try to avoid dependencies like the plague. We may soon be just trying to explain stuff to robots and having to deal with AI integrations everywhere. As a final thought you may find this blog post of interest regarding DNN stance regarding a migration to .Net Core https://mitchelsellers.com/blog/article/the-technical-future-of-dnn it summarizes a lot of lengthy discussions the team had about this subject. Things may change in the distant future but right now we are focusing on improving DNN rather than migrating it. |
Beta Was this translation helpful? Give feedback.
-
You need to understand again that because you created an issue does not mean it will be handled quick or at all. The list of issues here are to inform potential contributors. I do tackle issues I care about in a particular order, security, then things that affect me or my clients, then anything I know a sponsor of mine needs, then from oldest to newest. Each contributor is free to prioritize any other way too. So, it's not that nobody cares to touch your particular issue, just nobody got to it by the time you did. And it was obviously important for you so you submitted a PR. That is totally fine, don't blame the community for not handling your issue fast enough. During that time hundreds of other issues probably got handled.
We have a few "teams", for instance:
Now if we are talking EVOQ, this is a commercial project and developers that work on it are getting paid. They can pay them because they sell EVOQ. it is based on DNN Platform and they often contribute back bug fixes to this repository when it is appropriate to fix it for both DNN and EVOQ. Now if they build something new or fix something that does not exist in the platform, they obviously won't make that available for free. They have their own separate support channels and they prioritize what they do based on what their clients need. So for instance, if you were an EVOQ customer, you could contact their support channels and then have some reason to be mad about not taking care of your issue because you are paying for such things.
Well that's the exact reason we can't just break the ecosystem to migrate to .NetCore. Making that move would break all 3rd-party extensions. So if you don't have to deal with existing sites and value .NetCore more than the maturity of DNN. By all means, change platforms to what you like. And as a final thought, still don't know why you want .NET Core |
Beta Was this translation helpful? Give feedback.
-
I was out of the office when all of this came in, but I'll just add a little bit more here as well. Technology selection is a very delicate undertaking and is riddled with risks, pros/cons, and adjustments. Microsoft is for sure moving in the direction of .NET Core, much larger percentage of my own business is .NET Core based than otherwise right now, but that doesn't mean that .NET Framework isn't neeed, or even the RIGHT solution. .NET Framework has a much different support pattern, it has a lot more adoption base and history. It is possible to set-and-forget with minimal risks. It also can perform well and handle various workloads. .NET Core is the new shiny, it is faster, but it requires a complete shift to the nature of what you are doing, and how you support business. I personally find that when it comes to DNN usage, I favor a hybrid approach, which I've blogged about and talked about in the past. The fact of the matter is that there is NOT a single way to transition from WebForms -> Anything else. This means, regardless of if any future "DotNetNuke" like product exists, you will be 100% required to re-do major portions of your codebase. For most people the juice isn't worth the squeeze to do it. Especially considering .NET 4.8 is supported until 2032 at least as-is. Any platform that you use, .NET Core, .NET Framework, Angular, React, Vue, Bootstrap, etc comes with a set of risks. Your pathway forward will be often dictated by the direction of that product. Early adopters for example of AngularJS (1.x) got a real taste of the bad with the major changes that had to happen when you move forward. For those of us that are responsible for technology stack selection these are things that we have to address every day. As to your notes about issues or ignored issues. Our community is strong, there was a history (Pre 2019ish) where the community was not fully driving direction, managing pull requests, etc. Since then however we try to be inclusive, but we do ONLY accept changes that are not going to have a negative impact on the community or the product. As such, if a solution will result in a one-sided fix, or might break something from elsewhere it is possible we will need to request changes or adjustments. Often times, those come in from the contributors, but again, we may not be able to drill 40+ hours into trying to help get a partial fix over the hump. |
Beta Was this translation helpful? Give feedback.
As @sleupold the real issue is that System.Web, which is an underpinning requirement for DNN doesn't exist in .NET Core.