A little over a year ago I wrote a blog DNN, .NET Core & .NET 5 which was a follow-up to my article from 2018 DNN, .NET Core, and the Road Ahead. Over the two years since the first post was authored, we have seen incredible change within the DNN Platform as well as the entire .NET ecosystem. As we continue to progress forward with the DNN Platform project it is important for us to validate the technical future and ensure that we are progressing in a manner that is aligned to the best possible future for our project.
Recent Technical Successes
The past two years have afforded the DNN Platform some amazing technological improvements that continue to enhance the capabilities of the platform. These enhancements help to provide better developer experiences, improved security, and higher quality code that is easier to maintain. A few of these key successes in the past two years include:
Dependency Injection Support & Streamlined APIs
Supporting modern programming principles is important, not only for attracting new talent to the community but also for improving the capabilities of the platform itself. Great strides continue to be made with additions of support for Dependency Injection across the DNN API’s and the best part is we are seeing contributions to this effort from new contributors to the platform, a truly great sign!
Async Support
Microsoft introduced support for async/await a number of years ago, however, using async/await within DNN Platform was not easily possible until the 9.8.0 release. Adding this support allows developers much more flexibility in which API’s they can consume and gives new opportunities for performance management.
Code Quality & Standards Improvements
We have globally enabled StyleCop to help enforce programming best practices and will soon be adding static code analysis to the project to review for code smells, performance, and security related issues, in addition to the current standards & compliance issues. This is all in an effort to improve the stability of the codebase.
Removal of Telerik
I blogged about this in detail in my Emerging From the Past: Moving Beyond Telerik post. However, this is the single biggest accomplishment for the community in recent times. It was not possible without contributions from multiple community members, and a starting base of code provided by DNN Corp was part of the entire solution. We still have additional work to support the removal of Telerik by default; however, the fact that 9.8.0 can be utilized without Telerik is HUGE!
Community Involvement
From my perspective, activity within the community is a critical and key indicator of success. The DNN community continues to show very strong signs of activity, including an increase of more than 25% in community contributions to the platform as compared to a year ago.
.NET Core & DNN Platform: Coming to Terms With Reality
The most common question that I get as the technology leader is what the plan is with regards to .NET Core. Considering that .NET 5 came out this week, I thought it was timely to close the loop on this aspect of our technology future.
Understanding Our Limitations
Two years ago, I outlined a pathway forward that would have transitioned DNN Platform to .NET Core in a manner that would have allowed for a side-by-side transition effort. That plan was reviewed by Microsoft and others as being achievable, however, it came at an extreme cost - estimated at almost 8,000 development hours. Following standard consulting rates, that would have a financial cost of at least $850,000, if not more.
We worked pathways to try and secure resources, including discussions with DNN Corp about the possibility of getting resources. It just wasn’t possible. In addition to this, the window of opportunity closed very quickly on that transition plan, as it hinged upon functionality provided by .NET Core at the time that allowed running on .NET Core or on .NET Framework. In the end, Microsoft decided to stop supporting that model which makes the possibility of a smooth transition an impossible feat.
We are an Open Source project, fully maintained by unpaid volunteer resources, including myself. This means that we have to understand the limitations of what we can reasonably accomplish within a given period of time. The new Resource Manager included in DNN Platform 9.8.0 is a prime example of our resource limitations. The job was completed; however, it took longer than I expected. We have to have the perfect combination of individuals that are WILLING to contribute and AVAILABLE to actually perform the work.
This isn’t new. This isn’t unique to the DNN Platform. It is a fundamental reality of Open Source projects. Right or wrong!
Respecting our Community
Given the changes in pathway possibilities, we also have to take a step back and ask if we are doing the right thing for our Community. DNN Platform is nothing if we don’t have a passionate community there to help us along the way. Over the past two years, I’ve spent a good amount of time talking with community members of all types. It is clear that a transition to .NET Core now would result in literally everything (themes, modules, etc.) not working and requiring a complete rewrite to work in a “new” .NET Core solution.
This isn’t an option for our community. They need to have great support for the technology that we have. This isn’t a negative thing. It is a true crossroads for our project whereby we have to admit what we are and what we are not. David Poindexter has a larger blog post discussing this long term strategy coming soon..
DNN Platform is the largest .NET Based Application Framework/CMS, with a huge user base. Yes, we are built upon the .NET Framework. This is not the new and shiny technology. But it isn’t technology that has no support either. Microsoft will be supporting our CURRENT version of .NET Framework until at least 2031 which means that we actually have a technology lifespan that is more than 3x that of a .NET Core based solution. (Due to the 3-year lifecycle of .NET Core)
.NET Core Options
For those that have a requirement of having a .NET Core, options do exist that might help you fulfill those needs.
- Hybrid DNN + .NET Core - This is a model that I have personally utilized many times in the past 3-4 years. I’ll be giving a session on this architecture at DNN Summit in February 2021 as well. Basically, by leveraging DNN for what it does best you can also use a .NET Core-based application in a sort of Microservices manner to get the best of both worlds.
- Orchard Core - This is a Microsoft employee-driven project. It is not quite to version 1.0 yet, but it is anticipated very soon.
- Oqtane - This is a project of Shaun Walker. It is .NET Core/Blazor based and is currently in version 1.x with version 2.x in the RC stages.
As we know our purpose better, we will continue to explore options to work with various other technologies to keep options available for community members.
The Road Ahead
So, where do we go from here?
The future is looking incredibly bright for DNN Platform. Community contributions have increased by more than 25% in the past year. We continue to remove technical debt, resurface desired past features, and add new functionality. Our processes and procedures for creating releases continue to improve. If we stay the course, be true to ourselves, and strive for continued greatness within our lane, the future is bright and exciting! We appreciate all your continued support and contributions!
This post has been cross-posted to my DNN Community Blog