Semi-Automatic DNN Module Installation Packages

Recently I have been building more DotNetNuke modules than in previous months and I found myself spending a fair amount of time building installation packages to test my modules on my secondary DotNetNuke portal. After spending more time than I care to admit manually copying these files over, I created a simple command line batch program and added it as a post build event in my project. This way every time I re-compile my module Visual Studio will automatically create my installation package. Below I will provide a bit of direction as well as providing a link to download my sample .bat file.

Overview

In the end for MOST DotNetNuke module projects the file structures are very similar, in the root of the project you have your .aspx files, in an App_LocalResources folder you have your .resx files and in the obj\release folder you have your .dll(s). Well using this overall structure I created this simple batch process to copy the files as needed. This example is using the standard file structures for a compiled module using C# and the templates from BiteTheBullet.co.uk. Other solution structures might require additional steps.

The Batch File

When I created the batch file I used a very simple approach by creating the installation package using 6 distinct steps. First I copy over the .resx files, then the .SqlDataProvider files, then .ascx files, then any .aspx files, and lastly the .dnn and .dll files. You will need to simply modify the two path sections for each XCOPY statements. The first is the copy from path, this would be the full path to your project, the second is the path to the location that you would like the installation package to be created. Be sure that for all 6 statements that the second path is the same, as DNN installation packages are all created in one folder.

Sample make.bat file

Using this batch file, you simply need to zip the files to create your installation package. Below I will show you how to have Visual Studio automatically execute the batch script on each build of your module.

Visual Studio Integration

The process of setting Visual Studio to execute the .bat file after each build is as simple as adding a post build event to the Build Events section of your project properties. Right click on your project and select "properties", you will see the below window. Switch to the Build Events view.

In the post-build command line section you simply put the FULL file path to the .bat file that you created based on my example from above. Now, each time you build your solution the files will be copied successfully.

Conclusion/Disclaimer/Words of Caution

This article is designed to be a quick overview of a method to create semi-automatic DNN module builds. You MUST sanity check all XCOPY statements in your created .bat file to ensure that you will not accidentally overwrite or modify any files that you did not intend on modifying. XCOPY does NOT notify you about overwriting it simply does it expecting that you knew it would!

This is a great way to help automate your build processes. If you need assistance setting this up please use my support forum that is available on this site!

Posted by Mitchel on Sunday, January 06, 2008

Tags: DotNetNuke, Tutorials

Comments

Personally, I use the method of allowing DNN to create the package for me, but I love this article. What a great idea!

By Will on Thursday, January 10, 2008 at 4:47 AM

Comments from the following blog entry: Semi-Automatic DNN Module Installation Packages, located at: http://www.dotnetkicks.com/opensource/Semi_Automatic_DNN_Module_Installation_Packages

By DotNetKicks.com on Thursday, January 10, 2008 at 4:49 AM

Doesn't your bat file script copy in the wrong direction?

Shouldn't you be building your module in a \project\mymodule\ folder and *then* deplying to the \website\DesktopModules\mymodule\ folder?

Am I missing something obvious here?

By Alan A on Tuesday, February 19, 2008 at 6:00 AM

No, by default you should be building your modules inside of a DNN installation. This keeps all project references correct from the templates, and is your "development" environment.

From there you need to create an installation package which you can use to install the module on a different DNN system, and that is what this script does is copies all of the files from the locations within the DNN system on the dev system to the separate location where you can maintain install packages.

By mitchel.sellers@gmail.com on Tuesday, February 19, 2008 at 6:31 AM

To share my methods : I have two bat files in my DNN project solutions. One is a 'deployToTestSite', which does a straight copy of all of the various bits and pieces of a module into the targeted test site. I have a series of test environments, and the batch file takes in a parameter to determine which one to direct the installation to. This requires either manually creating the module, or using a module package. My other batch file zips up the various bits and pieces from a module into the module zip file. It's parameterized for release/debug, plus uses the same version naming as the individual components. Thus a global find/replace in the solution updates both the assembly versions and the version of the zip file. This batch file also creates the help packages and correctly versions them as well, and moves the newly-created package into the install\module directory of the chosen test environment, as well as my chosen publishing folder for easy FTP.
I don't, however, hook it up to the build - it's a manual, post build step for me.