DotNetNuke Deployments

Has anyone successfully used Octopus for deployment of sites using DNN (formerly DotNetNuke) as CMS? Wondering if this is a recommended use case, and what the potential pitfalls are.

Hi Adrian,

We tweeted about this, but so far no luck with anyone responding!
We don’t have any specific experience with DNN so could only provide generic advice …
Of course leaving this open, we might get lucky with someone stumbling in and providing some detailed information.


I am new to Octopus deploy. Trying to figure out if it can handle deployments for DNN. A basic DNN installation looks like this.

• Bin
• DesktopModules
o MyModules1
o MyModules2

• Portals\default\Skins
o MySkin1
o MySkin2

• Web.config

Most common scenario we run into DNN deployment are

  1. Add/update modules files
  2. Add/update skins
  3. Update web.config

Let’s take case of a new module. A module is nothing but a web application project. When we deploy we copy the dll output of the web application to bin folder of dotnetnuke website and rest of the controls and other static resources are deployed to a folder under DesktopModules folder. The folder is generally named after the module.

The exact same concept applies to skins where a given skin can be its own web application project and dlls are pushed to root bin and static resources are deployed under skins folder.

The biggest challenge is that you have different location for assembly files and different location for static resources. You can’t just take a build output and copy it to the root of website.

I am assuming if I need to do this using OctopusDeploy I can create a Nuget Package which has the structure maintained in it or may look at custom installation directory for each project.

Let me know if this is a right approach or is there a better way of doing this.


Hi Vinay,

Thanks for getting in touch. And thanks for the detailed explanation.

So I have two suggestions. One is to create multiple packages of the components like you said and create a step for each with the custom installation directory option.
The second would be to have a singular package, deploy it to the package directory as we do, and add a postdeploy.ps1 to move each directory from your extracted package to their final locations.
These would be the only options with Octopus’ current features.



I have been successfully deploying DNN with Octopus Deploy. I wrote a blog post that discusses the steps I took. As I mention in my post, it may not be the best way to do it, but it might give you some ideas.


Hi Colin,

AWESOME post, thanks for sharing! I don’t know if there is an easier way for you to solve your issue for the packing part of the problem due to TFS, but Ill have a TFS expert take a quick look over the post.
For anyone who has the ability to use either TeamCity or Jenkins or other, the best option sounds like it would be octo.exe pack. This command doesnt need a NuSpec, infact it won’t take one! It blindly packs everything in a directory it is pointed at.
That way you could get your DNN site packaged very easily, if you aren’t restricted to TFS.


Hi Colin,

I read through your post and it looks like you’ve got a pretty good process down. As Vanessa suggested, you could look at octo.exe to do the packaging in an additional or post- build step, or you could create a nuspec file that contained everything you need, but I think your way sounds a bit more straightforward. And I’m with you - I don’t like modifying the build template if I can avoid it.

The MSBuild argument you’re using is something I haven’t actually used before. It’s quite a nice way to add some new build behaviour! I’ll have to look into it.

Great blog post. I’m sure I’ll come back to it.

Damian B

Thank you for your feedback.

I will look into octo.exe. If I get a chance to implement a DNN deployment,
without first converting to a web application, I will be sure to blog about
it. I don’t think it will take much modification to the TFS build process
template to call octo.exe. It is something to stew on, anyway.


Just for module deployments to production, could you copy your zipped modules out to the install directory, and then in PS make a call to /install/install.aspx?mode=installresources This way you separate your base install from module deployments.


I finally had a chance to look into your suggestion and I think it’s great. I wasn’t aware of the /install/install.aspx?mode=installresources option. I did some searching and there is very little documentation or mention of it. I’m not surprised I didn’t find it when searching for a solution.

I think this will solve two problems. My solution only handles module upgrades; installations are manual. This will help automate them. Second, it might eliminate the cumbersome database synchronization step.

I am going to see what I can put together.


We’ve been deploying over 75 packages using the step identified by Patrick for the past few years and this has been great.

We deploy all of our skins, modules, etc. this way and don’t worry about the base DNN installation as it’s not changing with any frequency for us.