I’ll be the first to admit that this blog post should have been written a few weeks ago, however, a number of items needed to fall in-line before I could give this post justice. Within the DNN Technology Advisory Group (TAG) the future of DNN as it relates to .NET Core has been discussed at length many times. These conversations have come to multiple conclusions in the past, however, in the most recent discussions, thanks to some clarity by Microsoft an immediate term decision has been put in place. In this post I hope to try and share the highlights of those discussions, the reasoning behind the decision and the road ahead, at last as it appears now, for DNN.
.NET Core? What and Why?
This is not a post to explain what .NET Core is, or why you want to care about it. However, it is important to at least have a basic understanding of WHY this is such a critical decision point for the DNN Platform. Three years ago, almost to the day, Microsoft released a new thing called .NET Core. .NET Core is cross-platform, open source, and works quite differently from the current ASP.NET technology stack.
In the past three years, we have witnessed .NET Core learn how to crawl, walk, run, drive a car, and go off to college. The pace of change is unprecedented compared to what we have seen with .NET Framework. There have been major feature additions, upgrades, breaking changes, confusion on support, and a lack of clarity from Microsoft on direction. With the release of .NET Core 3.0 coming at some point in the future, Microsoft has finally started to set some ground rules that help to set a future course.
I just recently wrote a blog .NET Core / .NET Framework My Perspective On The Future that dives in deeper to the positioning of all of this. I suggest, reading this if you have time, before continuing on this post.
The Future of DNN: Community Input
Before I get into the specifics of .NET Core and DNN, I think it is important to look at the future of DNN and what the TAG group has solicited as feedback for items that are “important” for the community. It is this feedback that has been paramount in deciding the future direction of the DNN Platform, at least for the near term, as in the end, DNN would not exist if it wasn’t for the active & engaged EcoSystem that surrounds it.
Upgradability or Long Term Support of Current
Although not universal, it was almost universal that there needs to be some migration process available for developers. If not an upgrade path, a truly long-term plan needs to be set forth on the current platform for those that exist in the DNN EcoSystem.
Right, wrong, or indifferent we have hundreds of millions of dollars of extensions built upon the DNN Platform. A majority of these extensions have been developed on the WebForms development model as it is the one that has been around the longest time. Everyone understands that the platform needs to grow, but the key is that we cannot kill off the community that is already there, we need them to continue moving forward.
Admin Experience (PersonaBar) Needs Fixing
When discussing the most current needs, it has been unanimous that the PersonaBar needs to improve to resolve issues with: missing features, bugs, lack of accessibility, lack of mobile support, and more. Everyone knows that any transition to .NET Core, or otherwise, will take time, working to secure the PersonaBar functionality and ensure that we have a stable, usable, solution for users will be paramount to keeping the existing customers happy while any transition occurs.
Performance & Stability
The next most common concern with the community was around performance and stability of the DNN Platform. Over the years the DNN Platform has grown greatly in size, and with that growth, there are areas where performance has been degraded, or some instability introduced. Button clicks that don’t work, or performance issues that just haven’t been addressed yet. These issues are often exaggerated on installations with large numbers of portals, users, pages, or heavy traffic.
Being able to handle customer loads with consistency was listed as a key element.
Documentation
The final key discussion point was around documentation, We have an amazing platform, however, the documentation is severely lacking. This makes many things difficult to accomplish with a lack of standard documentation and resources. Over the 15 years of development that make up the DNN platform, we have fragmented API models that make discovery of actions often times an exercise of hide-and-go-seek rather than simple discovery. This adds to a barrier to entry for those new to the platform.
Why is .NET Core Complicated for DNN?
There have been many comparisons to other platforms and projects as it relates to migration to .NET Core. As I mentioned in my other blog, each project is going to go about things differently. For DNN we have a few key things that make our life a bit interesting as we move forward.
Heavy Dependency on WebForms
Many ASP.NET features have carried over to the .NET Core world, however, the WebForms development model in which DNN and many modules are based on have no support in .NET Core. Nor, is there any plans from Microsoft to support this model. This is the single largest hurdle for DNN Platform in two ways.
First, it is a huge hurdle in that the entire DNN Platform is based on the WebForms pattern. The building of every page, the loading of themes, the placement of modules, caching, URL rewriting, etc. are all using the WebForms pipeline for implementation. Sure, DNN has an implementation allowing developers to use “MVC” in their modules. Hover, that implementation was done by simply “adding” MVC to the WebForms pipeline. Changing this is a big undertaking and will require re-writes to a major portion of everything that makes DNN what it is today.
Second is the impact on others in the community. We do not have a solid transition plan, and once we remove WebForms from DNN all extensions that rely on WebForms, some of which even in 2018 CANNOT be done in a different manner, will no longer work. This is a problem that doesn’t have to be solved 100%, but future support for current users is at least a priority.
A Data Provider That Doesn’t Support .NET Core
Additionally, behind the scenes, DNN utilizes a component called PetaPoco to do many of the database operations. This is often referred to by the DNN name DAL2. This library at this time does not have any support to run on .NET Core, following the PetaPoco project online there appears to be some recent activity towards supporting .NET Core, however, that progress is not all that far yet.
Ideally, a new version of DNN would utilize a more standard solution for data access. My preference would be to utilize EntityFramework Core to follow along with the .NET Core world. It is doable, but it would require the re-writing of every single database call in the system. This is hundreds of thousands of lines of code that would need to be adjusted.
An API Model That Doesn’t Support Current Standards
Another consideration for migration to .NET Code is adherence to current coding standards and best practices. One of the key selling points of .NET Core is native support for Dependency Injection, composability, and the ability to easily test your implementation. The DNN Platform API’s at the current state does not follow any consistent structure, offers very limited support for Dependency Injection, and the platform as a whole doesn’t support these concepts for downstream users.
If we want to attract a new developer audience, those that are looking at .NET Core, it will be important for DNN to follow the design patterns as close as possible. The lower we can make the barrier of entry the better. It would be far easier to just be able to develop the .NET Core way, rather than the DNN .NET Core way! But to do this, a major refactoring would be needed.
What is the Cost to Migrate?
The question of what the cost to migrate would really be, in terms of developer hours, or some other quantifiable cost. This is a question that has received a lot of discussions, and the current determination is that we cannot easily put a solid number of this, until we decide exactly how much compromise we can have on breaking changes, etc.
Regardless of how we slice this, I think the best case scenario we would be looking at a migration process that would be in excess of 8,000- 9,000 hours including quality assurance time to ensure that features are working. There are many unknowns so this number could be grossly underestimated. Having completed many migrations from WebForms -> .NET Core myself I’m highly confident that it is not overestimated.
In the end, with a community-driven effort, in a perfect world would be something that would take years to complete.
Hidden Costs
I do believe it is worth noting here that there are also hidden costs once the platform would be transitioned to .NET Core. The support model of .NET Core is vastly different than that of .NET Framework. With a best case support lifecycle of 3 years, if we were to manage the release of DNN on the same day that Microsoft releases .NET Core, our community would need to shift their focus on upgrades and management of websites.
Right, or wrong, we have thousands of sites on versions of DNN that are 2, 3, 5, 10 years old, including some early DNN 1.0 sites are still in use today. That practice on a platform where security support ends after only a short three year period would be something that could not continue.
As a development community, this also will add slightly to the ongoing management of the project as we will have to make sure the entire platform stays current.
Do We Have to Migrate
This is a question that just recently has become more clear. The short answer is a simple NO, we do not have to migrate. .NET Framework, including WebForms as I mentioned in my other post will be supported at a bare minimum to 2027, we have time.
However, we would be remiss, if we didn’t start an action plan to move forward. The writing is on the wall that the true future is .NET Core. But how we get there is more important than the fact that we get there. A .NET Core DNN without the community is nothing more than another open source product without a backing.
What the TAG Group Decided
With all of this, it is important to understand what the DNN TAG group has decided to do. Acknowledging all of the above there is a concerted effort to help improve the DNN Platform and migrate us towards a future for all. The immediate term goals have been identified as follows.
- Fix the PersonaBar! This is the number 1 priority with a lot of work included in 9.3, the primary focus on the 9.4 release. Fixing issues, adding features back that were missing, improving performance, and accessibility of the PersonaBar are all on the docket.
- Improve the quality of the existing codebase. Multiple rounds of optimizations have already been implemented, however, there is a lot more work to be completed. This effort is to follow coding best practices and bring code to a level of consistency that will allow for easier refactoring of the APIs as we transition.
- Start to architect a new API pattern that will support .NET Core Concepts, including Dependency Injection. We have abilities to write .NET Framework code that will utilize the same principles, restructuring the current API’s will be a great start to move content forward.
- Work to make as many projects within DNN Platform .NET Standard compliant as possible. By making sub-projects .NET Core compatible this will allow us to better understand what code CAN work on .NET Core and what cannot. This will be paramount to keeping the scorecard on the future.
- Move the project forward, removing old-unused methods, as soon as practical. An official deprecation process was created in June, this process will be followed, but will allow a clear timeline to cleaner API’s
In addition to these priorities, we will continue to monitor the Microsoft progress with .NET Core. If a situation changes that will allow a more aggressive timeline the group will reconsider. We will get there but the key is to get there with a great product, and with our community intact as much as possible.
In Conclusion
I hope that this post helps to set the stage to all of the discussion and activity that has transpired in the past 5 months. For those wanting to get more involved the Technology Advisory Group meets weekly Tuesdays at 2 PM Central, I can gladly forward the information on those meetings to anyone that wants to participate.
As the leader of the group, I’ll work to get information such as this out to the community that is unable to attend these meetings. One week after each meeting, the meeting agenda is also available in the community blog.
This post was cross posted from my DNNSoftware.com blog.