How to automate the packaging of your DNN Module

Originally posted as a tutorial on Christoc.com

I must admit, the work I have done over the years with DotNetNuke has involved working with modules that I control, build, and have a say in. I am set in my ways of how I like to do things, and believe that my approach to DNN module development is one of the easiest approaches to the DNN platform, because of this I have put a lot of time and effort into my Module Development Templates.

Occasionally I come across other people’s modules in my consulting work, and it tends to frustrate me when I have to do things outside of my own little “perfect module development environment”. I want to be able to switch to “Release” mode in Visual Studio and build, and have the scripts package the module I am working on so that I can easily deploy it to a customer’s development or staging environment. I had just such an experience this evening, working on customizing a module for a customer, and they had the Source to a third party module that I needed to make changes to. There is no packaging or build process anywhere inside of this module, even to the point where there are missing files in the “source” project itself.

I decided I must do something about this, so I took it upon myself to wire up my custom MSBuild scripts into the project so that I can easily build and deploy without having to go through the hoops of using the Host/Extension packaging process. Here are the steps you can use to integrate the scripts that are used in my Module Development Templates into your own existing modules (even if they weren’t built with the templates originally).

The steps below assume you are following my recommended development environment (read here)

1. Delete all source code and start over from scratch with my templates installed.
1. You are now done, congrats!
2. If you really don’t want to go through step #1, you can skip it, but you must then go on to Step 2 below
2. Open your project in Visual Studio
3. Install the MSBuildTasks project from Nuget:

PM> Install-Package MSBuildTasks

4. Create a BuildScripts folder in your project
5. Add two files (source for each here)
1. ModulePackage.targets
2. MSBuild.Community.Tasks.Targets
6. Right click on the project in Visual Studio Solution Explorer and choose “Unload Project”
1. Save changes if prompted
7. Right click on the unloaded project and choose the Edit option
8. At the bottom of the file, before the </Project> section add

<PropertyGroup>
  <Extension>zip</Extension>
  <DNNFileName>CHANGEME.dnn</DNNFileName>
  <PackageName>CHANGEME</PackageName>
  <MSBuildCommunityTasksPath>$(SolutionDir)\Build</MSBuildCommunityTasksPath>
</PropertyGroup>
<Import Project="BuildScripts\ModulePackage.Targets" />
<Target Name="AfterBuild" DependsOnTargets="PackageModule">
</Target>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />

9. Change the “CHANGEME” text to match the name of your .DNN file and the name of the ZIP file that you want the package created as.
10. Save the Project changes.
11. Right click on the project in Solution Explorer and choose Reload Project.
12. Switch into Release mode in Visual Studio and do a Build of your project.

This should create two files, ModuleName_Version#_Install.zip and ModuleName_Version#_Source.zip.

What I typically do then is install the module to a test DNN install to make sure that everything is working correctly. You’ll want to make sure that the ZIP files created contain all the right files, and they get installed correctly, so a test installation is the best way to go through that process.

If something fails, try to track it down, then do another Build in Release mode, rinse and repeat the installation process in your test install until you get everything working properly.

Now going forward, after you do a release, you go into your AssemblyInfo file, change your version number there, and into your .DNN File and change your Version number there. Next time you build in Release mode the module will create a new VERSION number ZIP file, leaving your last version builds there as well.

Note: These instructions are using MSBuildTasks.1.4.0.74, if you have a different version you might have to change references to MSBuild in the Targets file