Semi-Automatic DotNetNuke Module Package Builds Revisited

29 Apr

Back in January I made a post here about creating semi-automatic module packages on the fly from within Visual Studio.  The method I showed at that time was a little bit primitive but it worked perfectly.  Recently I have had some time to refine the batch script itself as well as the integration point to the DNN project inside Visual Studio.  My recent changes now allow me to make 2 small changes for each project and builds work as I expect, it also creates a conditional system that can handle file deletions as well as dynamic loading of debug or release .dll files to the package.  This posting will cover this new process in detail..


In the end for MOST DotNetNuke module projects the file structures are very similar when using the WAP model for development. In the root of the project you have your .ascx, .dnn, and .css files.  In your App_LocalResources folder you have your .resx files and inside your obj folder you have your .dll(s).  Well using this overall structure I created this simple batch process to copy the files as needed to an entirely different directory location.  This example is using the standard file structures for a compiled module using C# and the templates from  Other solution structures might require additional steps.

The Batch File

The batch file is the first part of the process, we must create a file that will clear the output location, and copy over all needed files.  I broke this portion of the file into six individual steps, I will discuss each of these below.  You can also download an example file via a link at the bottom of this section.

Part One - Define Varibles

@ECHO off
ECHO %1 is the build type
ECHO Declare paths needed, package path is cleaned at start
set project= "C:\Inetpub\wwwroot\dnn470\DesktopModules\YourModule"
set package= "C:\ModulePackages\YourModule"

This step is the most complex of the entire process the first 3 lines cleanup display.  The %1 portion is the Debug/Release value that will be passed from Visual Studio, it references the first command line flag.  The last two lines of this section we define a variable for project and package.  These are the paths to our respective module and package location.  This is the only value inside the batch file that will need to change from project to project.  Please be 100% sure that you have the proper path in place for package, ad the next lines of the file will clear this path on each build of the module!

Part Two - Clear Package Directory

ECHO Delete Existing Files from package location!  CAREFUL!!!
ECHO Y | DEL %package%\*.*

This first line is another comment, this ia a VERY risky line of code, if your package path is incorrect this will do an unconfirmed deletion of files, PLEASE BE SURE TO SET THIS VALUE CAREFULLY!.  This step is needed to ensure that if a file was removed from the module it is also removed from our install package.

Parts Three to Six - Copy Standard files

ECHO Copy resource files
XCOPY %project%\App_LocalResources\*.resx %package%

REM Copy User Controls
XCOPY %project%\*.ascx %package%

REM Copy DNN File
XCOPY %project%\*.dnn %package%

XCOPY %project%\*.css %package%

The above items simply use the set project path and wildcards to copy the respective files to the package location.  If you have other files types, such as .aspx pages you will need to add additional steps for each additional file types.

Part Seven - Copy .dll Files

REM Copy DLL Files, note use of flag to grab debug/release depending on passed value
XCOPY%project%\obj\%1\*.dll %package%

This is a key improvement from my previous implementation of this automated process.  In here we copy the .dll files from the obj directory, however we rely on a command-line parameter to determine if we pull from the Debug or Release folder.  That is where the %1 comes into play.

Now that you have created the .bat file I recommend saving it inside a "Build" folder inside your DotNetNuke module solution.  The remainder of this article will be focused on that implementation.  Download a copy of the above batch file.

The only step after this batch completes is to zip the files into a package for installation.  If you have a command-line zip utility available you can use that to truly automate the process.

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 events area we can use a few macro values to our advantage.  First we use the ProjectDir value to get the path to the root of our project.  Then we put in the rest of the path to the batch file created earlier, in this example it was called build.bat and placed inside the build folder.  The last element that we use is the ConfigurationName value, this provides us Debug if in debug mode and Release if in release mode.  This is that extra parameter that allows us to truly build an accurate installation package.  The standard configuration of Post-Build Events is below.

VS Properties.

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 be very careful when working with this script as the package directory is automatically cleared each time this is executed and the warning messages regarding deletion are by-passed.  You must also validate that the XCOPY statements in the file are all that are needed to copy your module insallation files. 

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!  Please share any feedback below!

tags: DNN, Tutorials
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Connect with Mitchel

I hope the information here has been helpful. To stay connected you can also subscribe to blog updates via email, contact Mitchel about consulting services, or reach out for assistance via CodeMendor

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.