Setting up your DotNetNuke Module Development Environment (How to install DNN)

Installing DNN is an important step in the process to getting a DotNetNuke development environment configured. You can follow the tutorial below for How To Install DNN — you can even use this for a production installation if necessary.

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 for customers that use your extensions.

I recommend that each developer have their own local development environment, with a local IIS website running DNN (DotNetNuke), and a SQL Server database for the website, typically also running locally. Having an individual development environment makes group module development far easier than if you share environments/databases.

For the past few years, I have used a Virtual Machine environment for my DNN development. I set up a new VM per customer that I utilize — that allows me to segment the work and ensures that I don’t contaminate one environment with information from another customer. For a while I used Virtual Box, but as of late I have switched to Hyper-V.

Choosing a DNN (DotNetNuke) Version

Choosing a version of DotNetNuke (DNN) is important when you start your development for a 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 5.6.1? 6.2.6? 7.0.0? 7.0.6? Based on the answer, you can determine what version of DNN you should set up as your development environment.

You shouldn’t be developing on a newer version of DNN than what you have running in production. While there are ways around this, I am not going to go into the details in this tutorial.

As a developer working to create modules and release those, you might have production sites running on the latest 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’ll probably say no, but from a business perspective, you might say yes — and here’s why. Not everyone upgrades DotNetNuke websites as they should. In fact, some people never upgrade. While I don’t advise that approach, it’s a fact of life.

If you compile your module against an older version of DNN (e.g., 6.2.6), it will likely run on every version released since then. DNN strives to maintain backward compatibility. Though this isn’t always possible, it’s usually effective.

You might also want to use features only available starting with a specific version (e.g., workflow in DNN 5.1). In that case, you may choose not to support older versions out of necessity — minimizing your market but simplifying your development cycle.

Chris’ advice as of February 2021:
You really should be running DNN 9.8 or greater at this point, and remove all Telerik dependencies. There are too many security vulnerabilities in earlier versions. Encourage your customers to upgrade too.

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 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 the DNN source, and using the INSTALL package makes your environment cleaner.

We aren’t going to open the DotNetNuke project itself — so why keep unnecessary files? Also, the source package is notoriously harder to work with.

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

Chris’ advice as of February 2021:
You should have ditched the professional (Evoq) editions long ago. DNN Corp is no longer actively adding features to the paid version — it’s just about subscription revenue now.

Installation Configuration

Once you have the version and package selection out of the way, you can begin the installation process.

1. Download the INSTALL package of the DNN version you want to use.
2. Extract the files to a location of your choice (e.g., C:\websites\dnndev.me\).
   • Note: You may need to right-click on the ZIP and click Properties → Unblock before extracting, to prevent install issues.
3. Set up IIS and point to the extracted folder.

Setup IIS (Internet Information Services)

IIS is the web server that comes with Windows. You need to install it from “Turn Windows Features On or Off” in Control Panel. Enable all required features for running DNN (see screenshots in the original tutorial).

Then:

• Create a new IIS website (or use an existing one and add a binding for dnndev.me)
• Point it to the extracted DNN folder

Set File Permissions

This step causes a lot of trouble if skipped.

1. Right-click the folder where DNN was extracted
2. Go to Properties → Security
3. Add Modify (or Full Control) permissions to the application pool identity

You may optionally change the application pool to run under Network Service instead.

Database Configuration

DNN requires a SQL Server database. While SQL Express with file-based storage can work, a full SQL Server setup is preferred.

1. Install SQL Server and enable SQL Server Authentication
   • If not enabled, go to SSMS → Right-click server → Properties → Security → Choose “SQL Server and Windows Authentication mode”
2. Create a new database (e.g., DNNDEV.ME)
3. Create a new SQL login (SQL Auth) with db_owner access to that DB

DotNetNuke Installation Screen

When you browse to http://dnndev.me, you’ll be presented with the DNN install screen.

• Fill in host username, password, etc.
• Under Database, choose Custom
• Enter SQL Server name and the DB credentials from earlier

Optional config:

• Set objectQualifier to dnn_ to support dev environments where this is required
  • Not usually needed in production
  • Helpful if you plan to distribute modules to customers who use object qualifiers

DotNetNuke Module Development

To get started with module development, check out the tutorial on how to install our Module Development Templates.

This tutorial is based on original instructions provided by Chris Hammond in an old blog post, which became the DotNetNuke Wiki entry for Module Development Environment Configuration.