· Chris Hammond
Last Updated
Including additional DLL's in an MSBuild script for Module Packaging
Learn how to automate module packaging using MSBuild scripts instead of NANT in our latest blog post. Plus, discover how to include DLLs for smooth deployment.

Late last year I created a blog post and video about a new version of the module development template that I released on GitHub. This new template uses MSBuild scripts instead of NANT scripts to automate the packaging process for the modules built with the template.
The MSBuild script works well out of the box. To package your module, you simply change into RELEASE mode and then execute the build.
If your project contains references to DLLs (in the website’s BIN folder) that you also need to package up so that you can deploy them with the module, however, things become a little murky. Earlier today, Bruce posted on that original blog post asking how to include those DLLs in the build script so they get packaged automatically.
I thought this would be easy—simply add a new line to the MSBuild file for the DLL (two actually, so that you can target both the INSTALL and SOURCE packages that get built). The existing DLL gets pulled in with the following line (this line is found twice in the modulepackage.targets
file):
<Copy SourceFiles="$(MSBuildDnnBinPath)\$(AssemblyName).dll" DestinationFolder="$(MSBuildProjectDirectory)\Package\bin"/>
So you would think adding another one would simply be:
<Copy SourceFiles="$(MSBuildDnnBinPath)\$(AssemblyName).dll" DestinationFolder="$(MSBuildProjectDirectory)\Package\bin"/>
<Copy SourceFiles="$(MSBuildDnnBinPath)\SOMEDLLNAME.dll" DestinationFolder="$(MSBuildProjectDirectory)\Package\bin"/>
But if you do a build and check the packages, you’ll find that the DLL doesn’t get included.
What’s Going On?
It should be that easy. I puzzled over this for a while and figured something out—something I didn’t realize. Visual Studio actually caches the MSBuild file. So if you make changes and then try to run a build in RELEASE mode, you won’t see those changes take effect.
The Fix
What do you have to do? Unfortunately, you have to close the project and reload it.
This is definitely a pain, but in the long run, as easy as the scripts make packaging modules, I think that the few times you have to restart the project isn’t that big of a deal—as long as you remember that fact.
Updating the .DNN Manifest File
One other thing to remember when you are packaging a module is that you need to tell DNN about the DLL that gets included in the package. You do this by adding a couple of lines to the .DNN
manifest file.
For example, this:
<component type="Assembly">
<assemblies>
<basePath>bin</basePath>
<assembly>
<name>dnnsimplearticle.dll</name>
</assembly>
</assemblies>
</component>
Becomes:
<component type="Assembly">
<assemblies>
<basePath>bin</basePath>
<assembly>
<name>dnnsimplearticle.dll</name>
</assembly>
<assembly>
<name>SOMEDLLNAME.dll</name>
</assembly>
</assemblies>
</component>
The sample code in this blog post references DNNSimpleArticle, which you can download in C# or VB.NET from GitHub.
Good luck, and get coding!