Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

DNN 9 and the Future of the DNN Platform

Community LogoBackground

Two years ago, we began a discussion in the community about how to move the DNN platform forward.  Microsoft was hard at work on ASP.Net vNext, which was later renamed to ASP.Net Core.  At the time, I made the case for DNN making a radical departure from the Web Forms architecture that is the foundation of DNN today.  That new platform, DNN neXt, would have been built on .Net Core and would have benefited from much of the work the ASP.Net team was doing to modernize and cleanup .Net.

Unfortunately, the more we looked at the challenge, the more we realized there was no way to get to the new platform without massive disruption to the current ecosystem.  Some users would be stuck on the existing platform with no path forward.  We also realized that the vision for .Net Core would not be fully realized in v1.0 and that significant APIs would be missing from the platform for an indeterminate amount of time. As work on DNN 8 continued it became obvious that DNN neXt was going to take a major engineering effort beyond what was first envisioned.

Laying the Foundation

With these problems in mind we decided to take a step back and re-analyze the problem.  First and foremost, we had a few goals that we wanted to accomplish for the platform:

•    Reconstruct DNN to minimize our reliance on Web Forms architecture
•    Provide developers the freedom to use a variety of frameworks
•    Protect customers’ existing investments in DNN
•    Provide a fully supported upgrade path for everyone

While DNN neXt would have removed the reliance on Web Forms, it would have done so at the expense of our existing customers. We could definitely do better.

DNN 8 was a major breakthrough for the DNN platform. DNN developers were finally able to leverage the ASP.Net MVC framework to create modern DNN apps. In addition, DNN 8 introduced the concept of SPA modules which utilized a modern client side development approach to building modules for DNN.  With these changes, developers were able to freely mix-and-match Web Forms, MVC and SPA based development on the same page, and even within a single module.


DNN 9 represents the next step on our journey towards creating a more modern platform and further minimizing our use of Web Forms.  I am happy to announce that by the end of 2016, DNN will introduce DNN 9 with a brand new administrative experience that replaces the dated Web Forms based admin and host modules that we use today.


In DNN 9, we’ll be moving the Evoq Persona Bar concept to the DNN platform and completely rebuilding the control panel, admin and host modules to use this new framework. Stay tuned for future blogs where we’ll dive into the Persona Bar and admin experiences in detail and show how DNN 9 changes the way you think about building modern websites and web applications with DNN.


David Cuthill
Sounds great. Please contact me.
David Cuthill Monday, September 26, 2016 4:43 PM (link)
Jason Sigman
Sadly, this article underscores the reason why many have stopped developing modules for this platform. It is more of a playground for engineers than a reliable tool for business.

It only takes a few bad upgrade experiences to force paying business customers to switch to an alternative platform and ultimately the developers follow the money.
Jason Sigman Tuesday, September 27, 2016 11:59 AM (link)
Tony Henrich
Good work. What do you have in mind for DNN 10? The posted roadmap is outdated and doesn't show anything for 2017.

I saw your presentation of the new DNN 9 UI. I still prefer doing my edits in one monitor and viewing the preview in another monitor. Personally I feel he flyover edit model adds extra mouse clicks because you have to hide and show it to edit and preview. It good for one-off edits . Certainly good for mobile devices. I assume all these screen are using responsive design. Just want to make sure that doing edits and previews can still be done in other browser tabs or windows without the flyover opening every time I refresh because it's open in one of the other tabs/windows. Not a big concern.
Tony Henrich Tuesday, September 27, 2016 12:56 PM (link)
2sic Daniel Mettler
That's the way to go :) Awesome! We're back on track.

I'm not so sure about React vs. Angular 2, but I believe any decision is better than none, and a clear focus is better than a "everything should work" strategy. Love it :)
2sic Daniel Mettler Thursday, September 29, 2016 3:32 AM (link)
Javier Rodríguez
Then, If I understood correctly, DNN9 will support Web Form modules, so, it won't be running on ASP.Net Core. Am I right? Then, one more question, any Idea how long DNN will support Web Form modules?
Javier Rodríguez Thursday, September 29, 2016 1:37 PM (link)
Joe Brinkman (CM)
@Jason I am not sure why you think the platform is only a playground for Engineers and not a serious business tool. Every business understands that technology is constantly evolving and that failure to evolve your platform to keep up with technology guarantees obsolescence. Having said that, I want to be clear, that our decision to move to a lighter weight development style for the admin experience, has no impact on how developers create modules for the platform. You are still free to develop using Web Forms, MVC or SPA frameworks regardless of what we do with the admin tools.
Joe Brinkman (CM) Friday, September 30, 2016 1:23 PM (link)
Joe Brinkman (CM)
@Javier - That is correct. We are not converting to ASP.Net Core at this point in time. We may choose to do so in the future, but that is a ways off at this point.

DNN is built on Web Forms and we will continue to support Web Forms for those developers who want to use it. DNN 9 is just minimizing our use of Web Forms as we think we can provide a better Admin Experience without using Web Forms. But if you love developing with Web Forms, then feel free to continue using it.
Joe Brinkman (CM) Friday, September 30, 2016 1:26 PM (link)
Tony Henrich
To the developers thinking about using MVC in DNN 8+, from my personal experience the DNN MVC support is crippled. I couldn't use it when I tried to create a prototype using the third party MVC extensions I wanted to use. DNN simply doesn't support the full spectrum of partial views which is an integral part of ASP.NET MVC. It was a road block. You can either use the standard WebForms which Microsoft continuous to support and will support for years ahead. They are just a ton of WebForms web apps around. MS will not abandon the technology any time soon.

However if you are starting fresh and want to use something newer, skip MVC and use Javascript and any of the JS frameworks and any JS based UI controls. Telerik, DevExpress, Infragistics and ComponentOne offer both ASP.NET WebForms and JS/HTML based UI components. Or any JS UI component since they are not dependent on the backend technology used. They only need to talk to an API like teh SPA framework in DNN.

The advantage of using a JS/HTML front end is usually they also work very well for a mobile device if they are using responsive design principles.
The drawback is that you might be writing a lot of javascript code. To alleviate some coding pain, I suggest using Typescript which supports strong types and object oriented principles like class and inheritance. You can have Typescript output classic ES5 Javascript which is compatible with all the browsers. Angular 2 is out and it strongly uses Typescript therefore you probably can't escape learning Typescript. All the ng2 examples I have seen use Typescript.

Personally I suggest dnnsoftware concentrates its efforts into the SPA framework. The MVC support is more like a hack and if it doesn't support the full ASP.NET MVC functionality then why bother. You will get very frustrated if in the middle of your development project you wanted to use a critical ASP.NET MVC functionality and find out it doesn't work in DNN. It will be a big waste of time. Just do the development in WebForms or the newer SPA. Stay away from DNN's MVC. I wasted about 3 months trying to get it to work for my needs. Granted I was working on the RC versions. I got excited for nothing. It was a frustrating experience. The worst part is when you seek help in the forum and no one answers for the simple reason that very few developers are using MVC in DNN module development and understand what's going on. You're on your own. There is ZERO advantage of using MVC in DNN. I hope this message gets across to would be developers.

I keep hearing the message from dnnsoftware that they support ASP.NET MVC when the true story that the support is full of potholes. I also feel sorry for the forum posters who are seeking help in the forums for MVC. If you can an error you can't explain, it's probably because of DNN's wonky MVC support.

To be honest I wish they remove MVC support from DNN 9 so people don't fall in that trap. Two options only => WebForms and SPA.
Later when DNN is truly built on MVC using ASP.NET Core, if they every go there, then it can say it supports ASP.NET MVC.

I will post this as a blog comment and put it in the forum. I want this message to spread.

Tony Henrich Friday, September 30, 2016 2:02 PM (link)
Katherine Moss
Love it! Sounds like just what we are looking for, though if I may make a request? Joe, you probably are aware of all of the feedback I gave you and David on twitter, along with many other community members. The DNNConnect crew is aware as well of the accessibility pitfalls in DNN in its current form. Could you perhaps base the development of the new admin panel less on mouse-overs? That would be extremely helpful for blind users if customizations weren't required to be made for us to manage it. And also, anything that is expressed via an icon must have alt-text on it in order to comply with WCAG. Thanks for listening!
Katherine Moss Sunday, October 02, 2016 11:18 AM (link)
Scippy One
I think Dnn is losing the needle of the compass, I agree with Jason and Tony. Before, after the announcement of the stop of webform support, many old developers choose to stop the support and develop modules after many years of work and investments on Dnn. Now, DNN is loosing the most daring and newest developers after that DNN declares that an upgrade will not be carried out with full support to new versions of the framework.
Every developer that DNN community lost is a innestimabile loss because develop for DNN is very complex and requires very advanced knowledge hard to find, unlike many other more simple frameworks where for each developer loss ten are find, on DNN one lost is one lost.
For example, my company has based its business on Ventrian PA modules and their loss has forced us to seek other alternatives difficult to find on DNN, at today not replaced with any other modules.
The business is created on the basis of safe and lasting choices ... everything it is starting to miss on DNN!
I think that DNN before you say something should think well its choices because can not afford to make mistakes again!
Scippy One Sunday, October 02, 2016 2:34 PM (link)
Joe Brinkman
@Scippy - I honestly don't understand your comment since we have not stopped web form support and don't have any current plans to do so. We have made a decision to add support for other types of web development and to move as much of the core platform away from web forms as possible for a variety of reasons. That however does not limit or remove the ability of module developers to continue using web forms.

The loss of DNN developers that you mention had nothing to do with our addition of MVC and SPA support. Many of those developers left long before we started work on DNN 8. In fact if anything, we have lost more developers because we waited too long to support alternative frameworks.
Joe Brinkman Monday, October 03, 2016 12:55 PM (link)
Tony Henrich
@Joe Why don't you talk about the MVC support and its direction. Are you planning to improve it or what we have now is DNN's technical limit of incorporating MVC in a WebForms app?
Tony Henrich Monday, October 03, 2016 1:48 PM (link)

Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (22)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (270)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?