Written By Timo Breumelhof.
2025-06-04
This post reflects my personal opinions and is not an official statement from the DNN Community or the DNN Platform team.
DNN Technology
DNN has always been based on the .NET Framework and WebForms, initially developed in VB and now in C#. As with every technology, this has advantages and disadvantages.
A major advantage of WebForms is its stability, especially in contrast to the relatively short and sometimes frustrating support cycles of .NET Core.
A disadvantage is that WebForms is not viewed as cutting-edge by some developers. However, it is important to realise that WebForms offers a lot of functionality that you would have to create yourself in any other technology.
Some worry that Microsoft support for WebForms will stop, but I’m not convinced support will end anytime soon, as many of their platforms still rely on it—such as Office 365.
Also, with the release of Windows 2025, we are again assured of .NET security updates for at least the next 10 years.
Ever since the Community has had control over DNN, a lot has been done to introduce new technologies into the platform.
Recent DNN Modernizations
Examples of this include the MVC module pattern, dependency injection, Web API, and more.
But the main DNN rendering engine is still based on WebForms. It offers a lot of functionality out of the box, at the cost of not having 100% control over the finer details of page rendering.
Take it one step further...
During an Open Content meeting, Sacha Trauwaen (the developer of Open Content) shared an intriguing idea.
Sacha needed full control over the output rendered by DNN to be able to adhere to strict Content Security Policies for a client. He was unable to achieve that using the current WebForms rendering.
He created the concept of a secondary DNN rendering pipeline based on MVC 5 without WebForms. At that time, he showed just the content of an HTML module, without a theme.
I really liked that idea, as it seems like the natural next step for DNN. This new way of rendering would potentially align more with .NET Core’s approach without breaking every existing DNN site. Essentially, it introduces the concept of MVC-based pages rather than just MVC modules.
The MVC Rendering Pipeline: A Proof of Concept
We created a “playground” to see if, by introducing a secondary DNN MVC Pipeline, we could take a next step in reducing DNN’s dependency on WebForms.
We discussed this with a small group of DNN friends to determine the best direction—with Sacha doing most of the heavy lifting.
Key Concepts of the MVC Pipeline:
- A secondary DNN MVC-based pipeline will be available, not using any WebForms to render the page.
- There will be no functional changes to either DNN or the database, as that would only lead to scope creep.
- You will get the choice to use either WebForms or the new rendering engine, per page or portal.
- All modules and extensions used on an “MVC” page will have to support MVC rendering.
Supporting Extensions for MVC Rendering
No module currently supports this kind of full MVC page rendering.
Even the current MVC-pattern modules will probably need some (minor) work to be usable on an MVC page. But obviously, this will be a lot easier for modern SPA or MVC modules than for classic WebForms modules using lots of WebForms controls.
Instructions for adding support to existing extensions will be published later.
Sacha already added support to the most-used skin objects, the HTML module, and Open Content for this proof of concept.
Why Should the DNN Community Care?
The primary goals of this initiative include:
Cleaner HTML output, removing things like unnecessary <form> tags and ViewState.
Improved security, enabling support for strong Content Security Policies to help achieve an A+ security rating.
Faster page load times and better SEO.
Deprecation of outdated features like JavaScript unload handlers.
The ability to create Razor Themes.
Simplified Azure firewall configurations for access-restricted websites.
DNN Code Quality
Despite the effort involved, this new rendering pipeline was relatively easy to implement—a testament to DNN’s high coding standards and solid architectural foundation.
Evolution vs. Revolution
The major advantage of this new rendering pipeline is its ability to coexist with the existing WebForms-based approach. This allows users to adopt the new rendering method at their own pace while maintaining support for older modules on other pages.
While radical changes might sound exciting, they often come with unintended consequences. For a community as large and diverse as DNN’s, gradual evolution is the most practical and sustainable path forward.
Current Status
This proof of concept is currently being developed mainly by Sacha Trauwaen.
Peter Donker has already spent considerable time reviewing the code, and he and Sacha are working on an installable proof of concept.
We demoed this concept at the DNN Connect 2025 conference in Spain, where it was received with great interest.
Stay Updated
This community initiative represents a possible exciting step in DNN’s evolution—balancing innovation with continuity. Your feedback and support are crucial in shaping its future.