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.

Enterprise Extension Development with DNN Part Two

A few weeks ago I set the stage for this series of posts with my Enterprise Extension Development with DotNetNuke Part One post.  This article, the next in the series, ended up getting delayed a bit.  As many of you know there has been a lot changing within the DotNetNuke world, as all of this unfolded my priorities were pulled from these posts to other areas of concern.  Now, I'm back on these posts and want to make sure to dive into this in detail.  In the first post of the series I covered the high-level details.  The reasoning behind this series, and the main goals that I hope to accomplish by putting this information out there.  This post is dedicated to the development environment, and development structure for our projects. 

Importance Of Project Structure

Why is it so important to start with project structure?  Why not start with development environment?  Or local DotNetNuke installation?  The answers to these questions are actually fairly straight forward if we take a step back and look at this process from a bit of a different angle.  You as the reader is looking at this post for information specifically on how to develop for DotNetNuke, how to use the platform effectively.  This is great for the person that wants to learn all there is to know about a solution.

However, in the end, when working with an Enterprise grade solution built with the DNN Platform it is important to look at what is necessary to get someone up to speed.  Enterprise projects might change hands between multiple developers, often times with differing experience levels with .NET and/or DotNetNuke.  To have a successful project of any scope the "time to develop" needs to be low.  In this post we will look at setting up a DotNetNuke project WITHOUT having a DotNetNuke installation on your machine.  This means that any developer, experienced with DotNetNuke or not, will be able to pull your code, build the project, and successfully deploy a change if necessary.  No custom configuration of their machine, no local installation of DotNetNuke, no third-party downloads necessary(Only necessary for new project templates).  Just simple development!  Once we get to this point with a single DotNetNuke module, we will start to talk about sharing and structure within the module(s) to support extensibility.


To make all of the items discussed in this project work you will need to first download and install Chris Hammond's DotNetNuke Module Development Templates.  For the current time, these templates will work as a good starting point for our development efforts.  In the end, you might customize the templates a bit to handle your specific environment, however, this will work to get going.

Secondly, all of the documentation/processes that are discussed in this post assume the usage of Visual Studio 2012 and the C# programming language.  None of the items here are different if using VB, I just don't have detailed examples.

Creating Your Project

The first step in the process here is to create your new project using the C# template.  At this point though we are going to start to diverge from the standard process.  As you select "File" -> "New Project" in Visual Studio and select the C# Module development template, we are not looking to create our project inside of a /DesktopModules/ folder of a DotNetNuke installation. 

When selecting the the save location, simply find the location that makes sense for your environment.  In my case we utilize TFS for source control.  We have multiple Team Projects for some of our larger clients and then a "small projects" Team Project for those little jobs.  This means that we could be creating a project on a disk location of D:\tfs\companya\projectb\R1\Source\ or any other arbitrary location.  This portion of the process TRULY doesn't matter.  Just find the location and create your project.

Try to build your project.  You will notice that it fails to compile and will complain about MANY missing references.  This is to be expected! 

NuGet to The Rescue!

A while back I blogged about the recent existence of NuGet packages for DotNetNuke.  In that post I eluded a bit to the purpose of these packages and how they can help resolve issues, but didn't give a lot of clarity.  NuGet is a Package Management platform, a system that allows developers to consume packages within their projects.  In this context a package is defined as a consumable assembly/project/etc.  For example there are packages for jQuery, jQueryUI, and many other frameworks. 

With these new DotNetNuke packages we have the ability to consume DotNetNuke in our projects, allowing us to compile/reference DotNetNuke without needing to setup a full development environment.

With your newly created project open the "Package Manager Console" which is available from the "Tools" menu.  This will open a command prompt window for working with NuGet packages.

From here, simply type the following, without the quotes.  "Install-Package DotNetNuke.Core -Version 7.0.0" and press enter.  This will download the Core package that has all of the base dll's necessary for working with DotNetNuke.  (NOTE: If you would like, you can update the -Version 7.0.0 portion to -Version 6.0.0 if you would like to target DNN 6.x and later rather than DNN 7.x and later.)

Once you see confirmation that the package was installed, compile your project.  You will notice that your project now compiles successfully. This right here is the first step to successful enterprise development.  Once this package has been installed, any user that gets a copy of the project, regardless of where they store the code files on their machine, they will be able to compile your code.  Compiling with this template in release mode will additionally create the proper DotNetNuke installer, so your project will be set to go! 

What's Next?

Now that we have a clean project, that can be compiled anywhere, we can start to move on to the next step of the process.  Determining exactly how we should be structuring our projects.  If you are working on a solution with a single extension, the steps up to this point should give you a bit of flexibility that already will reduce some of the burden of DotNetNuke development.

In the next posting, which will be posted in the next few days, we will dive into the specifics of larger projects, those with more than one extension, and sharing between them all.  Feel free to share your comments/feedback below.

This article was cross-posted on my personal blog.


Awesomeness! Can't wait for the next post.
RBeaujard Monday, July 29, 2013 4:30 PM (link)
Fabio Parigi
Hi Mitchel
very interesting!!!
Ill try asap
You tell us that with NuGet I can share my developing phase etc... but how I can test it inside DNN like a running module... I need a DNN working installation on my pc? or not?
Fabio Parigi Thursday, August 22, 2013 5:56 AM (link)
Jon Sommervold
Hi Mitchel!

First of all thank you for publishing these blog posts - it's really helpful!!

I did face a couple of problems when following the steps you outlined though.

When creating a module based on Chris Hammond's development templates on a "clean" pc, I got the message:
"The web application project DNNModule1 is configured to use IIS, The web server '' could not be found. it seems that it is necessary to do some of the configuration described in the docs for Chris' dev templates...?

After configuring my environment as suggested above, I did get an error when compiling the module:
"the name clientapi does not exist in the current context".
I did find a class called DNNClientApi, but this didn't contain the correct method(s).
I guess there's a change in the version of DNN which breaks the dev templates, and it only takes some digging before finding the reason why - I'll post back when/if I do!

Thanx again!

Jon S.
Jon Sommervold Thursday, August 29, 2013 8:34 AM (link)
Mitchel Sellers

That is very interesting on the templates. I am using an older one as I am NOT using the IIS setup on the module templates.

(Sorry, just saw this now.)
Mitchel Sellers Saturday, September 28, 2013 11:00 PM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (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