New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

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.

Two Great Frameworks That Work Great Together

A large part of life is about making choices. We make hundreds of decisions every day. Whether it is a mundane decision like what to eat for breakfast, or a life altering decision like whether to get married. For computer geeks like me it might be whether to use VB or C#, or whether to write my web app using Web Forms or MVC. Many of the choices we make in life are outward expressions of who we are. We often make choices not for any logical reason, but because of some emotional feeling that we have. Why does one developer prefer C# while another developer prefers Java?

As a development framework and platform, DNN has always catered to a broad development community. This is fundamentally what extensibility is all about – it is about allowing users to make their own choices. How do you architect the platform such that developers can swap out the default functionality with some alternate implementation? How do you give developers choices to use the framework and platform in a way that feels natural to them?


Shortly after DNN was created as a VB project, the developer community started asking for a C# version of the platform. For many developers it was not a question of whether they could learn VB or whether VB was good enough for the job, it was just that many developers preferred C# for their day to day development. A large number of organizations began adopting C# as their standard language and this increased year over year. Eventually, it was obvious that by remaining a VB only solution, that DNN was unnecessarily limiting users and organizations who would adopt the platform.

In 2011 we made the decision to adopt C# as the official language for DNN Platform development. Fortunately, thanks to the .Net framework, all the great DNN extensions written in VB continued to work. This change allowed DNN to address the concerns of the growing C# audience while still providing support for the VB developer community.

In 2009, Microsoft released the ASP.Net MVC framework. The MVC framework was intended to provide additional options for .Net developers who wanted to use a more modern approach to web development. MVC provided improved testability, better control over the markup that was rendered, cleaner separation between presentation logic and business logic, and a faster rendering pipeline. Unfortunately, adopting MVC for a platform like DNN would have meant making drastic platform changes. Also, many developers were happy with ASP.Net Web Forms and didn't see much benefit to making a transition to MVC. This was one choice that we could not give to our developer community... until now.

Last summer Charles Nurse began doing some R&D on Project Maverick. The purpose of the project was to determine the feasibility for supporting MVC development on DNN without introducing massive breaking changes. The hope was that we could leverage the MVC framework for doing module development without requiring the entire platform to be rewritten in MVC. Project Maverick was a big success and Charles proved that not only was it feasible to create modules using MVC, but that it wouldn't require disruptive changes to the core platform. MVC and Web Forms could work seamlessly together, even on a single web page.

The fruits of the Project Maverick effort will finally be released with DNN 7.5 when we introduce a new MVC module type. We are working hard to make MVC modules a truly first class developer experience in DNN and will support pretty much the entire ASP.Net MVC framework. There are, however, a few exceptions like Routing and MVC Areas which don't make sense in the context of a DNN site.

Implementing MVC

The DNN MVC implementation tries to stay very close to ASP.Net MVC. If you have built an ASP.Net MVC app then you should feel right at home building DNN modules using MVC. Like many modern development frameworks, we have favored a convention over configuration approach. The conventions are built into the DNN framework but can be overridden if necessary. This approach reduces development friction while still allowing for customization.


Building models for MVC modules doesn't require any special magic. In fact, you can continue using your favorite DNN data access techniques with your MVC modules. Your model is just an object that contains the data you want to display and it can be as simple or as complex as you like. Your model might be an existing DNN domain object like a UserInfo object or it might be some custom object that is specific to your module. There is no requirement to inherit from any base class or to implement any special interface. You just need an object – any type of object will suffice.


ASP.Net MVC views are somewhat analogous to the User Controls that you use for building DNN modules today. Unlike User Controls, MVC views are just the presentation template with a small bit of embedded presentation logic. Out of the box DNN 7.5 will support the ASP.Net Razor view engine, although it wouldn't be too difficult to support other view engines in the future. DNN implements a small view base class (DnnWebViewPage<>) so that we can inject DNN specific context that you can use for accessing common elements like the ModuleID, Module Settings or Portal Settings. The base class also handles wiring up DNN specific HTML, URL and AJAX Helper classes. The DnnWebViewPage class is similar to inheriting from PortalModuleBase for your User Controls and should be a familiar concept to current DNN developers.

In order to provide a more seamless developer experience, we have overridden some of the standard helper classes in ASP.Net MVC so that we can provide DNN specific implementations. The DNN specific versions will use the same API signature but are designed to function in a DNN site. For example many of the URL helpers assume that ASP.Net routing is being used. Since DNN relies on our own URL rewriting, we needed to change how URLs are generated using these standard helpers. This approach will allow us to support the same functionality that ASP.Net MVC developers rely on, but in a very DNN friendly way.

NOTE: The ASP.Net URL and AJAX helpers are not complete in this CTP, but will be available in later nightly builds or the next DNN 7.5 CTP.


ASP.Net MVC controllers are used to accept input from the users and then update or retrieve data from the model for presentation. Each controller defines one or more actions which are used for handling some user interaction in the module. Like views, controllers in the DNN implementation will inherit from a common base class. Not only do we add DNN specific context to the controller, but we also use this base class so that we can attach a custom ControllerActionInvoker to capture the output and inject it into the page.

Module Actions

The Module Action menu is a unique feature of DNN and doesn't have a corresponding analog in the ASP.Net MVC framework. Modules built using the Web Forms framework are able to implement an interface on the module controls which exposes custom module actions. Because of the differences between Web Forms and MVC frameworks we were not able to use this same approach. Instead we have created two custom method attributes (ModuleActionAttribute and ModuleActionItemsAttribute) that you can use to either create a single module action, or where you can identify a method that returns a ModuleActionCollection (the same basic method signature used for IActionable). These method attributes are used to decorate your individual Controller Actions where you need custom module actions. You can see an example of this in the sample code used on the simple MVC Html module.


It is still early in the DNN 7.5 development cycle and we have a long way to go until release this summer, but we are getting closer to wrapping up the core MVC development effort. If you are an ASP.Net MVC developer we hope you like this implementation. We think we have covered most of the mainline MVC features but would love to hear your feedback. If we missed some critical feature, or you find a bug with the implementation, we would love to hear from you. If you want to help on the development feel free to submit a pull request against the feature/8.0.0 branch.

We are beginning work on some sample MVC modules and some developer documentation with walkthroughs on the whole process of creating a module using MVC. The modules and documentation should be available in an upcoming DNN 7.5 CTP release.

You can play with the MVC bits today by downloading the DNN 8.0 source code from GitHub, downloading DNN 8.0 CTP 1. CTP 1 includes the core of the MVC development experience but is still missing some of the MVC helper methods.

NOTE: As part of this release we have increased the server requirements to ASP.Net 4.5. You will need to install this framework before installing this version of DNN.


Harry -
I understand still supporting web forms in dnn 7.5 but will they be totally removed with version 8?

Will version 8 be able to run on the 5 core or will old legacy code still require the full stack?

Webforms is such old & slow technology & even Microsoft has stated that they will not be supporting webforms on their new stack. Personally I think this gives DNN the perfect opportunity to start from scratch using the latest technology ( core - web api & mvc). Now is the time for DNN to break things & do things properly - start from scratch like the team have done by totally re-writing core. If DNN doesn't start from scratch then more than likely we (& I'm sure a lot more people) will have to move on. Although we currently maintain 400+ DNN sites, times have changed, technology has changed & we are looking to embrace all the new technology. We are not interested in a mix n match of old & new technology.
Harry - Thursday, March 19, 2015 11:09 PM (link)
Tony Henrich
Cool. Maybe it makes sense to have a DNN forum for MVC module development so people interested in can find everything related to it in one place?
Tony Henrich Friday, March 20, 2015 1:45 AM (link)
Joe Brinkman
I think there is a balancing act that is needed for DNN neXt (this likely will not be called DNN 8). I agree that we should not allow the current DNN technology stack to hold us back from building a great DNN neXt platform that is modern and forward looking. However, we should also spend some time leveraging those pieces of DNN that are well architected, that follow modern programming best practices, and that are not tied to Web Forms. I think a great example of this is the Folder Provider feature of DNN. The ability for content assets to live anywhere on the Internet or in your private network is a powerful feature that we certainly will want to keep. The core platform APIs for folder providers are fairly well architected and there is no reason to throw them out. Yes, we will need to rethink the UI and rewrite it for MVC, but that is very different from completely rewriting the feature.
Joe Brinkman Friday, March 20, 2015 7:15 AM (link)
Joe Brinkman
I'll see about creating a forum for MVC and SPA modules. Although CTP 1 only includes the MVC support, we will have SPA module support in CTP 2 so it is good to start the discussions about both of them.
Joe Brinkman Friday, March 20, 2015 7:16 AM (link)
Harry -
Joe - That's great to hear that you guys are really going to move forward properly & I hope others can see it is really the only way forward. Now I am really looking forward to dnn vnext :)

I am sure that you guys are thinking about it but I might as well mention it - is there going to be a skinning competition for vnext?

It would also be good if we could have an opensource module competition too. This would allow other programmers to look at the code to learn how to create more complex modules. I for one would like to see a few of us get together & create a universal module like the ventrian property agent module. Out all all the modules I seen it is one of the best modules around (even if it's a bit out dated now). Scott did an absolutely fantastic job on it!
Harry - Friday, March 20, 2015 8:20 AM (link)
Joe Brinkman
MWD - I think an Open Source module competition would be great. One of the challenges we have with these sorts of efforts is getting people to help organize and run the contest. If you or someone else would like to work with myself and Will Strohl, and you would lead the effort around organizing such a contest we would be very open to that. Part of making Open Source work is to spread the effort out over a large group of enthusiastic community members so that no one person gets overwhelmed with the effort. Right now some of our team leads are getting stretched pretty thin and we need others who can help take up some of the slack.
Joe Brinkman Friday, March 20, 2015 10:40 AM (link)
Tony Henrich
I would like to see a template for creating an MVC module coming out from One that's standardized and endorsed by them. One that shows best patterns and practices for creating such a module and which aspiring module developers would use as a base for their own. It needs to utilize APIs which covers at least 80% of module developers needs. The template needs to be maintained over time as new APIs are being added to DNN. It should be available via Nuget and Visual Studio gallery. When new ASP.NET developers see that DNN has a strong live market and open source module repository, they will have a higher chance in selecting DNN as their CMS against other competition. I personally learn a lot by looking at examples and other people's code.

Nobody wants to be in situation where they start developing a module for the first time and it's "Now what.. how do I start?" and be stumped.
Tony Henrich Friday, March 20, 2015 12:14 PM (link)
Mike Cox
I have been using DNN for quite a few years now, I have built my business using DNN and Ventrian modules. Ventrian modules made DNN worthwhile for me, I could focus on building instead of coding custom modules. Web forms has essentially crippled the UI of DNN. I can build anything with DNN/Ventrian, it is so flexible but my customers hate it passionately - they struggle with the simplest of content administration tasks. What you are proposing here does not make sense to me. Let's say you build a fabulous MVC module that will do everything News Articles will do - I will still need to build a new website to use this new module and move all the content into it. While this may well be an improvement, there is nothing selling me on staying with DNN. If I am going to have to rebuild a customer's site, I am going to choose a CMS or Framework that does not have all the web-forms baggage.

Mike Cox Friday, March 20, 2015 12:25 PM (link)
Tony Henrich
@Mike Cox You can still stay with DNN 7.x. It will still be updated for a while after 8 is released. It will be at least a year or much longer if there's a feature in DNN 8 that you really need that's not in an updated 7.x. By then there should be a migration path from News Articles. Looks like a business opportunity here. I read some complains that the Ventrian developer is not working on any updates. Maybe it's time for you to look for another News/Article module.

Not sure what you're complaining about. If you're using a third party module that not supported anymore and the developer is not interested in updating their modules, it's not DNN's fault. You have other options. As I mentioned, one of them is to stick with 7.x. It's not going away any time soon.

Also you can share why your customers hate DNN passionately. Maybe they are using it the wrong way. Maybe DNN guys will look into those issues and consider them. Any feedback is worth it. If people are complaining quietly, it does no one any good.
Tony Henrich Friday, March 20, 2015 12:55 PM (link)
Charles Nurse
This is a great intro from Joe on how we are adding MVC support. In the next few days I hope to complement this with the first installment in an MVC Module Development series.
Charles Nurse Friday, March 20, 2015 1:20 PM (link)
Brian Dukes
Mike, DNN 7.5 is still going to support Web Forms, it's adding MVC (and SPA) as additional options for creating modules. DNN neXt is going to be build upon ASP.NET 5, which does not support Web Forms, so it will, by necessity, be MVC-only. However, DNN 7 will still be supported (by DNN Corp and/or the DNN community) for years to come, while the DNN neXt ecosystem becomes more mature and DNN developers migrate their modules to support it and create new solutions for it. Creating MVC modules for DNN 7.5 will help ease the transition to DNN neXt somewhat, but there's still quite a bit of runway left before anyone should feel "stuck" with having to completely rename their site.
Brian Dukes Friday, March 20, 2015 1:33 PM (link)
Mike Cox
@Tony Henrich. I am sorry if I am coming across as a complainer, not my intention. I don't have any issue with Ventrian, the modules were very well written and continue to operate just fine in every version of DNN I have running. I don't think this thread is the right place to comment at length where the UI falls short, I have have been vocal in offering ideas for UI enhancements over the years. To start with, there are too many trips to the server for every text edit you need to make and that is the fault of Web Forms. I can see the logic of this release if the modules developers create for 7.5 will work in 8.
Mike Cox Friday, March 20, 2015 2:03 PM (link)
Brian Dukes
Mike, it probably won't be possible for modules written for DNN 7.5 to work in DNN neXt, because of breaking changes in MVC and the underlying .NET framework. However, the migration from one to the other will be much smoother than moving a Web Forms module directly. The SPA module type (basically plain HTML modules with web services) should be even easier to port (but, again, there will probably be at least some breaking changes in Web API).
Brian Dukes Friday, March 20, 2015 2:40 PM (link)
Tony Henrich
@Mike You can start a discussion in the forums to discuss DNN's shortcomings. I don't know about the many server trips on every edit. Seems like an implementation issue than a WebForms issue. Hopefully with DNN neXt, DNN will feel more like a SPA app with fewer postbacks and look fresher. Just like ASP.NET 5 is doing an overhaul in its architecture, DNN needs one too. I am always looking forward to better technologies which make me more productive. BTW, outside of DNN neXt, ASP.NET 5 supports WebForms, just not in the core assemblies. One needs to install extra libraries to support WebForms but if DNN next is targeting the core libraries only, I guess in this scenario WebForms is not supported. WebForms developers are not out of luck in ASP.NET 5.
Tony Henrich Friday, March 20, 2015 5:37 PM (link)
Brian Dukes
You're right, Tony, I should have said that DNN neXt won't use Web Forms because it's targeting .NET Core, not because it's targeting ASP.NET 5 (though, looking at, they may be calling Web Forms a part of ASP.NET 4.6, rather than ASP.NET 5).
Brian Dukes Friday, March 20, 2015 5:49 PM (link)
David Poindexter
Fabulous Joe - fabulous! Excited to get our hands on the CTP and start playing around. We are looking to port our modules to MVC/SPA as soon as possible.
David Poindexter Friday, March 20, 2015 11:14 PM (link)
Jaydeep Bhatt
Can we have a sample MVC Module Development Tutorial?
Jaydeep Bhatt Monday, March 23, 2015 3:18 AM (link)
Brian Dukes
Jaydeep, Charles is planning to do a blog series on MVC development. Also, you can follow to see the modules that are being built as part of DNN 7.5.0 (which will ultimately be examples of MVC development in DNN, though there may be non-best practices while they're still in development, e.g. the edit view in the HTML module uses bootstrap styles, but those won't be there in the final version)
Brian Dukes Monday, March 23, 2015 11:57 AM (link)
David Poindexter
Thanks Brian!
David Poindexter Monday, March 23, 2015 12:10 PM (link)
Scippy One
All links to are Page not found!
Scippy One Thursday, April 2, 2015 10:01 AM (link)
High on my wishlist is the ability to develop and debug DNN modules in VS without having to run DNN website. So just a lean MVC setup with a context object that mimics a DNN context. No more Attach to Process. Would that become possible? Anyone any thoughts on that?
Holoncom Monday, April 6, 2015 8:55 AM (link)
Joe Brinkman
@Scippy One - I've updated the links to point at the 8.0 Feature branch.
Joe Brinkman Monday, April 6, 2015 4:16 PM (link)
Horacio Judeikin
FYI all links are dead (,, etc.)
Horacio Judeikin Thursday, November 26, 2015 12:27 PM (link)
Brian Dukes
@Horacio, the 8.0.0 branch is now just the development branch, so the URL would be, but the HTML module was just removed, so it won't be there (if you want to see an MVC module, you'll want to look at
Brian Dukes Tuesday, December 1, 2015 10:19 AM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
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 (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (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)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out