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!

Setting up your Module Development Environment

Return to previous page

  • 4/7/2015



Setting up your Module Development Environment

Last updated long time ago



(Enter the content of this article below)



This page will be discussing the development environment that I configure when I am doing DotNetNuke module development.

In this series we will configure an environment that works well for individual or team development, using the WAP (web application project) model for our projects in Visual Studio. Each developer will have their own local installation, their own instance of SQL server (at minimum their own database on a shared SQL instance). You can go through this process using Microsoft SQL Server Express, but I would suggest using a development or other licensed version of SQL Server as Express can be a real pain in the rear some times.

There are a few assumptions made in this configuration.

  • You have Visual Studio 2008, 2010 or 2012
  • You have IIS installed on your Operating System and ASP.NET extensions are installed and enabled.
  • You have .NET 3.5 SP1 installed, DNN 7 requires 4.0+
  • You are using SQL 2005/2008/2012 (not express)
  • You are running Visual Studio "As Administrator" this is required because of the use of IIS see Microsoft's article here.

UPDATE for 1-24-2013 These instructions are now configured for DNNDEV.ME as your development environment instead of just DNNDEV. DNNDEV.ME is a registered domain which points to the loopback address of, so it will always resolve locally for anyone.

This page contains legacy information - the latest documentation on setting up the christoc module development templates can be read at here

So let’s get started:

Setting up your development environment

Setting up your development environment can vary based on what your end goal is. If you are doing module development for your own use, and within your own DNN environments, you can ignore a few of the settings below. If you are doing module development with the idea that you might turn around and give the modules away, or sell them, then you will likely want to follow the guidelines set forth below to support the widest array of DNN installation environments.

Choosing a DotNetNuke Version

Choosing a version of DotNetNuke is important when you start your development for couple of reasons. For modules that you are developing for yourself, you need to ask, what is the minimum version of DotNetNuke that you have in production. Are you running DNN 4.5.5? Are you running 4.9.5, 5.2.2 or 5.4.2? Based on the answer you can determine what version of DNN you should setup as your development environment. You shouldn’t be developing on a newer version of DNN than what you have running in production. As with everything there are ways around this, but I am not going to go into the details on that in this blog post.

As a developer working to create modules and release those, you might have production sites that are running on the latest and greatest version of DNN, but what about your customers? Or your potential customers? You have to ask yourself, do you want to provide support for really old versions of DotNetNuke? From a development perspective you will probably say no, but from a business perspective, you might say yes, and here’s why. Not everyone upgrades DotNetNuke websites as they should, and often times you will find that some people never upgrade. While I don’t advise taking that approach to managing a DotNetNuke website, it is a fact of life that people don’t always upgrade and there are thousands of people, if not tens of thousands, that have sites that aren’t running on the latest version of DNN. You should take that into account when you are doing your module development, if you compile your module against an older version of DNN then your module should run on newer versions of as well, for example. If you compile your module against DotNetNuke 4.5.1 it will likely run on every version of DNN released since then. Though there are extended cases where this won’t always work, DNN strives to maintain backwards compatibility, this isn’t always possible.

You might also want to use features that are only available starting with a specific version of DotNetNuke, such as the workflow functionality found starting in DNN 5.1, in that case you may choose not to support older versions of the platform out of necessity. This will minimize the market in which you can sell your modules, but also can make for less support and an easier development cycle due to the features that DNN provides.

Choosing a Package

Now here’s one that may baffle you a bit. I’m going to recommend that you use the INSTALL package for whatever version of DotNetNuke that you download. What? The INSTALL package? What about the SOURCE package? Well you can use the source, but you don’t need it. The module development that I’m setting you up for doesn’t require source, and overall makes things cleaner. We aren’t going to be opening the DotNetNuke project when we do our module development, so why have the files sitting around for nothing?

The steps for setting up your development environment will apply to both the Community and Professional editions of DotNetNuke.

Installation Configuration

Once you have the version selection out of the way you can go through the installation process. While I’m not going to walk you through the minutest of details of each step of installing DotNetNuke in this post, I will at least try to point you in the right direction for each step. In future writings I will be doing a series of posts about installing DotNetNuke in various environments that will go into further details. This post half assumes that you have configured DotNetNuke before.


Download the INSTALL package of the version of DotNetNuke you want to use in your development environment.


Extract the files in the INSTALL package to a location of your choosing, this location is where you will point IIS (the web server) when we can configure the website. In my example I extracted to c:\websites\\ (One item of note: you may need to right click on the ZIP file and choose Properties before extracting, on the properties window if you have an UNBLOCK option click that. Some versions of Windows have started blocking files within the DotNetNuke ZIP files, which will cause you problems later during the actual install.)

Setup IIS

IIS is the web server that comes with Windows computers. In our example we’re going to create a new Website in IIS 7.5 on Windows 7, this isn’t possible in Windows XP because of limitations with IIS v5.1, but is possible in other versions of IIS.

You should create a new website (*if you use an existing website in IIS be sure to add the HOST binding for DNNDEV.ME)*, and point to the folder where you extracted the INSTALL package.

If you are using IIS 5 or IIS 6 you will need to verify that ASP.NET 2.0 is selected on the ASP.NET tab (you can configure 4.0 as well).

We are setting up a website so that I can access for the development environment. The old configuration was for DNNDEV which required that you modify your HOSTS file in step #4, with this is no longer neccessary.

You may notice in my screen shot that my Application Pool is setup to Classic .NET AppPool, by default your application pool will have a custom name (in IIS7.5), you can change this if you wish, but if you change you will need to configure permissions accordingly. See step #5 for more info about configuring the permissions.

Modify the HOSTS File (not necessary if you use

If you are using DNNDEV.ME skip this step. In order to be able to access http://dnndev in our web browser we need to change the HOSTS file located in the c:\windows\system32\drivers\etc\ folder. You can open this HOSTS file with NOTEPAD or any other text editor. By modifying this file we essentially tell the computer that when we make a request to http://dnndev/ we should use the local IP address. See the screenshot for what this file looks like. Once you save this file you should restart your web browser to ensure that it has the latest settings.

Set File Permissions

Setting up the file permissions for your DNN install is often the step that causes the most trouble. You should right click on the FOLDER in which you extracted DNN (c:\websites\\) and choose properties. Choose the Security tab (if you don’t have a security tab you are likely using Windows XP and need to uncheck the Use Simple File Sharing option in the Tools/Options screen). You need to add permissions for the account in which your website is running under. You will want to setup the permissions to give the account Full or Modify permissions for the DNNDEV.ME folder. Which account you will use will vary based on your version of IIS, here’s a simple grid to see what the default account is for your version of IIS

IIS VersionOperating SystemAccount
IIS 5, IIS 5.1Windows 2000, Windows XPlocalmachine\ASPNET
IIS 6, IIS 7Windows 2003, Windows Vista, Windows Server 2008localmachine\Network Service
IIS 7.5Windows 2008 R2, Windows 7IIS AppPool\APPPOOLNAME

If you are using IIS7.5 you’ll notice in the above table that we have APPPOOLNAME in the identity, this is because when you setup a new website in IIS a new application pool is created. In place of you should type in the name of the application pool that was created (automatically during step 3). You can also bypass this and configure your application pool to use the Network Service account instead of a dynamic account.

Create Database

In SQL Server you should go through and create a new database. I always create a database with the same name as the website, so in this case DNNDEV.ME. Once you have created the database, create a user that can access that database. I always use SQL authentication, turn off the enforce password requirements, and give the user DB Owner and Public access to the DNNDEV.ME database. Remember the username and password you create here as you will need them when you walk through the installation process.

Access the Installation Wizard

Now you get to walk through the easy portion of the installation. You should load up your website in a browser, this may take a few moments, but when it does you’ll come to an installation wizard screen. Choose the Typical option and step through the process of installing DNN. When you come to the database configuration screen you should choose the SQL 2005/2008 option, uncheck integrated authentication and populate the name of your SQL Server (likely (local), ., or IPADDRESS), Database Name (DNNDEV.ME), Username and Password.
For the SQL Server name, if you open Microsoft SQL Server Management Studio, you can copy the name of the server (e.g. MYMachine\myMSSQLEXPRESS) from the connect dialog, or the Server Properties right-click context menu.
Now there are two additional options you can configure, normally I would tell you not to modify these, but from a development environment perspective I do recommend that you change the objectQualifier setting. It should be blank by default, you should type in “dnn” (without quotes), this will prepend “dnn_” to all of the objects that get created by DNN such as Tables and Stored Procedures. This is not something I recommend from a production stand point, but if you are developing modules for sale, then supporting objectQualifier in your development is recommended. It will save you time down the road if you have a customer who has an objectQualifier defined on their production databases. Step through the rest of the installation screens, you should remember your HOST and ADMIN passwords that you define as you get to those screens, you will need these when you login to your site later.
If you get a file not found, or a System.Security.SecurityException: then open the web.config file in the root directory of the DNN installation. Add the tag
This can go just after the section.

Modify the Web.config File

One last thing we need to change in our development environment is to configure a setting in the web.config file. There’s a setting called ShowMissingKeys which is by default set to False, from a development perspective I recommend setting this to be True. This will make it so that any text in DotNetNuke that is localized will be displayed with an L in front of it, to show you what is localized and what is not. This is important if you are trying to create modules that can easily be customized for other languages, the ShowMissingKeys flag will also cause DNN to throw a message in place when a string that should be localized is missing from the Resource Files (resource files are XML files that contain the language definitions for localization).

You now have your DotNetNuke Development Website configured. Your next step will be to Customize the Module Development Template

The templates (C# and VB.NET) are available at
To learn more about DotNetNuke in our instructor led classes check out the DotNetNuke Training page.
No sections defined
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out