DotVVM for modernizing Web Forms projects to .NET Core

[thabaum]

https://www.youtube.com/watch?v=NR-q5xCNFns

DotVVM video discusses modernizing a web forms applications to MVC on the fly... maybe something that can potentially help not just the project but module developers to help with the process of moving to .NET Core?

https://www.dotvvm.com/products

Looks like it is free and open source

https://github.com/riganti/dotvvm

[mitchelsellers]

I'm publishing a blog about .NET Core transition later today.

DotVVM looks cool, but there are a lot of proprietary things in there.

[thabaum]

I agree and look forward to reading your blog! I would like to see DNN module developers converting finally to MVC.

I just seen the subscription piece. From my understanding is it is free to use for commercial and non-commercial use and only developers that are needing to utilize more features need to pay the subscription to use features. When your subscription runs out you go back to the free version for features in Visual Studio. Each developer that wants to use this needs to get their own license.

[thabaum]

@mitchelsellers I read your blog recently.
Microsoft released a tool that is to help with the migration.

https://github.com/dotnet/upgrade-assistant

Expiration date is in 9 years and ticking... tick tick tick.

I believe the current community members and developers that would do just fine with a fixed version 9 for the next 9 years for their dying fleet of websites. Who is going to really desire to try to draw new people into what feels like could be a time trap? If so I need to get off this boat now.

I have been patiently waiting and looking for a lifeboat or a life ring from somewhere for the DNN community that could help make this a more near term reality if possible and everyone is on board. I am just looking for answers relating to DNN .NET Core stance and reading between the lines is a bit hazy in my opinion.

Bottom line: .NET Core is the now and future with websites that are modern, .NET Forms is a thing to migrate from or face major end of life issues in 2031. Am I correct?

And if DNN has no plan to convert, period end of discussion, then if you want a web application project to stay up to speed with latest .NET Core features you need to migrate everything on your own to something new anyhow.

So lets say I want a current DNN project to keep up with the future of .NET in mind, should I jump ship now and try to swim to shore by rebuilding in a system like Oqtane for Blazor? Bottom line, yes or no? I appreciate your feedback. Thank you.

[valadas]

A couple of clarifications

Microsoft released a tool that is to help with the migration.

This tool does not support WebForms, the main blocker to move to .Net Core is not really the fact we use .Net Framework but the fact that most of DNN uses WebForms. The PersonaBar really helped in that area but we still have a lot of extensible things that only work with Webforms like skins and containers and module settings, many providers, etc...

Expiration date is in 9 years and ticking... tick tick tick

Microsoft has not announced any end of life for .Net Framework, it will be supported until and well after Windows comes with it. So this clock keeps getting extended with each new Windows release. In contrast, support is pretty much guaranteed to end within 3 years of each .Net Core major release. I am not saying this is super bad, just illustrating that a 9 year ticking clock (which gets extended every year or two) is nothing to panic about right now.

I have been patiently waiting and looking for a lifeboat or a life ring from somewhere for the DNN community

Don't forget that this is an open-source project and that nobody gets paid to improve it, there has been massive work done from only a handful of contributors that moves us one little step closer with .Net Standard abstractions and a lot of work in Dependency Injection, removing Telerik etc. One cannot expect developers to invest the massive time required to completely remove webforms from the platform. But let's assume this is by some miracle done overnight, we still need to support webforms for 3rd parties for at least 2 major versions. And then, my guess would be that many of the existing module maintainers would simply abandon them.

I am just looking for answers relating to DNN .NET Core stance and reading between the lines is a bit hazy in my opinion.

In my opinion, there is no stance to have. We have stances on deprecation rules, on breaking changes, on licensing to keep the project open source and free, on security, on not being too opiniated, on many things. If anyone comes up magically with a PR that does not violate any of our existing rules and brings the platform to .Net Core, that would be welcome, but this won't happen quick, it may also never happen, but if it does happen, only time and contributions will tell.

So lets say I want a current DNN project to keep up with the future of .NET in mind, should I jump ship now and try to swim to shore by rebuilding in a system like Oqtane for Blazor? Bottom line, yes or no?

Can't decide this for you and I don't know everything that is out there so will focus on why I use DNN for most projects.

1. It is mature and stable
2. It has very clear path forward, deprecated APIs are clearly communicated, developers avoid unexpected breaking changes, maintainers really care about them too.
3. Best online community I have ever been part of, a lot of community members are very very experienced and have been doing this since almost the beginning of DNN.
4. It is just soooo extensible

Now should all web projects be built on DNN, totally depends on you, I use DNN almost exclusively because of the previous reasons and because I cannot be an expert at everything, I used to maintain Wordpress and drupal and many other sites built with various things, but I stopped doing that as I just can't be great at all of them and DNN always served my needs perfectly and I don't foresee it dying any soon.
Would I start a new project on oqtane ? Not with my current oqtane knowledge, I don't know how to develop for it, I did not find much documentation about how to do so, I don't know where to find oqtane modules, I only know 1 of the persons on the project and only by name. In contrast with DNN, I can find a lot of documentation, I know where I am going, there is a plethora of modules available including a lot of free open-source ones and I can reach so many competent colleagues on slack and github and even have direct phone numbers for many of them, so for me, I won't be leaving DNN for a while :) Now I don't mean that oqtane is bad by any stretch, I am just saying that it is new and cutting edge vs DNN which is mature and stable.

[mitchelsellers]

Daniel posted much of what I thought as well, so I will not repeat any of what he said, but will ad some clarity on a few points.

Expiration date is in 9 years and ticking... tick tick tick.

This is not the proper way to view this. Microsoft has a detailed Support Policy page that outlines the lifetime for .NET 4.8. Currently based on this Windows Server 2022 is supported through October 14th, 2031 and this will continue to roll out forward.

I'm not saying this is the best thing in the world, or that we have to bank on it, but at the same time it isn't a "the ship is burning and we have to rewrite everything".

This type of support model is vastly different from the 3 years only model that exists with .NET 6.

I believe the current community members and developers that would do just fine with a fixed version 9 for the next 9 years for their dying fleet of websites. Who is going to really desire to try to draw new people into what feels like could be a time trap? If so I need to get off this boat now.

As to the above, 10+ years of support is less of a time trap than the 3 years with .NET 6. We have to continue to draw people based on the merits/features

I am just looking for answers relating to DNN .NET Core stance and reading between the lines is a bit hazy in my opinion.

There isn't really any reason to read between the lines on our stance at this point. I blogged about this back in November of 2020, and David Poindexter also blogged about this topic. Given our current resources, the fact that NOTHING would be able to migrate as-is, we have to focus on doing what we can do.

If we get crazy amounts of volunteer commitment or something else happens, I do not see an immediate change.

Bottom line: .NET Core is the now and future with websites that are modern, .NET Forms is a thing to migrate from or face major end-of-life issues in 2031. Am I correct?

Yes, Microsoft has decreed that .NET 6 and later is the absolute future standard, but at the same time, per the above .NET Framework & ASP.NET WebForms does not have an end-of-life defined that is in stone. At this point 2031 is the latest max, the next OS release will almost be guaranteed push that date out. Yes, when it becomes EOL there will be concerns.

So lets say I want a current DNN project to keep up with the future of .NET in mind, should I jump ship now and try to swim to shore by rebuilding in a system like Oqtane for Blazor? Bottom line, yes or no? I appreciate your feedback. Thank you.

There are other options, for example, with many of our clients we do a hybrid approach for new projects. We use DNN for the things that we need it for, and we limit long-term risk on .NET 6..

[thabaum]

Thanks @valadas and @mitchelsellers as I read a lot including most blogs on this topic. I even read a your dnn 4 and 5 module book too!

After consuming all this information over a year in time now...

THE BOTTOM LINE:
• .NET Framework and WebForms is here to stay at least to 2031 along with DNN
• Each Microsoft Windows Server release will give clues for EOL for .NET Framework and ultimately DNN Platform.
• No hurry or interest to actually move DNN Platform to .NET Core due to keeping legacy app modules working for everyone with DNN using Webforms.
• No need to learn anything new if you are familiar with what DNN has and like it, stick with what you like.
• Build Hybrid deployments if you wish to use features available in other technologies such as .NET Core or any other modern stack available today.
• DNN has a huge community with lots of love and support, but only enough to support what it can with time allowed.
• Oqtane is not a CMS, it is a .NET Core Blazor modular app that can run both server and client side allowing developers to build installable components inside "modules" or "apps" to create something like a CMS, CRM, or whatever your heart desires including games and PWA's connecting Bluetooth devices or camera and mic features without a CMS system taking over the app feel.
• Oqtane would qualify for DNN users as a potential candidate for a Hybrid App solution.
• Oqtane is what DNN originally was, DNN has evolved with a large community supporting it as a CMS. Oqtane will not follow this path as it does not align with it's mission.
• Oqtane is in the early stages of being adopted, therefore has little to no support documentation and videos to help support it. It also has only a handful of community developers as compared to DNN.
• Module apps with ready to run on Oqtane are scarce.
• Build your own app you don't have to please community with avoiding breaking changes, however the workload is on you to figure out everything top to bottom to keep it secure and running as desired. Rely on strictly developer resources for help.
• It is ultimately up to a projects short and long term goals to decide which is going to be the right path. If you want to get up and running now and grab modules ready to go DNN is the way to go currently. If you are into building modern apps and app modules fire up Oqtane or any .NET Core app and in about 10 seconds depending on your system speed you are running the app and developing more real-time as it is the future.
• DNN does not currently have the resources and community support to migrate to .NET Core. Even if a sponsor would fix all of DNN, the issue is still about the community sites running WebForm modules. Unless the developer community decides a majority are ready for the move it is a dead topic. DNN is at this moment in time what it is and will be.
• DNN Community can focus on making DNN the best .NET Framework CMS without any huge changes to the .NET Framework itself, code away!
• To future proof DNN Modules and give a modern feel use SPA and SignalR when applicable.
• Both DNN and Oqtane are highly extensible.

Correct me if I am wrong on any now but I think I got all the talking points from all sides here.

Thank you all for your feedback I am really still at crossroads with a project and I should know the answer in a couple weeks as I am going to work with both DNN and Oqtane aggressively over the next couple months. Cheers!