DotNetNuke has long supported building modules as separate projects in Visual Studio.  With the release of Visual Studio 2005, Microsoft added a new compilation mode for web projects called Web Site Projects.  This required module developers to figure out how to work in the new paradigm since our previous module development methodologies would no longer work.  Anyone who was around for that transition knows how painful it was to relearn how to create modules.  The old methods no longer worked and the WSP model did not provide many of the same benefits as the compilation model in VS 2003.  Microsoft listened to the complaints of the DotNetNuke community and many other web developers who still wanted the old compilation model.  Their solution: Web Application Projects (WAP). 

WAP brought back the more traditional development style that DNN developers were used to.  Unfortunately there were some new kinks as well.  I have long advocated keeping my module projects separate from the DotNetNuke installation.  I create and destroy DNN installs quite a bit and don’t want to inadvertently delete some of my code during my frequent site purges.  Keeping my modules in a separate project directory allows me to delete websites without harming my modules.

The problem with this approach is that you need a method to actually install your module into your DotNetNuke site when you are developing and debugging the module.  You also want a solution that allows you to debug your project.  To resolve these issues, I rely on the fact that a Visual Studio project file is also an MSBuild file.

Many people are aware that Visual Studio supports post-build events.  This event occurs after the project is done building and can be used to copy the files to the appropriate directory.  Unfortunately, build events are really just glorified DOS batch files.  This is good and bad.  You can do a lot with DOS commands, but they are really not well integrated with the Visual Studio project.  For example, I don’t know of an easy way with the post-build event to determine which files are part of the project and which files are just extraneous documentation or sample files.  I often have extra files in my module folders during development that are not really part of the final solution.  The good side of build events is that they are fully editable within Visual Studio.

What many people do not know is that Visual Studio also defines some standard MSBuild targets that you are free to override.  By overriding the afterbuild target, we can now use MSBuild and Visual Studio to move our files for us.  My original build script, was a little “wordy” and was a little inflexible.  Andrew Nurse took my original solution and came up with a more flexible approach which still relies on the afterbuild target.

  <PropertyGroup>
    <ModuleFolder>Posh4DNN</ModuleFolder>
    <DNNDirectory>d:\websites\PSDemo</DNNDirectory>
  </PropertyGroup>

  <Target Name="AfterBuild" DependsOnTargets="DeployModule"></Target>

  <Target Name="DeployModule">
    <!--  
     We use CreateItem to ensure we pickup dynamic content 
    that may be generated during the build task -->
    <CreateItem Include="$(MSBuildProjectDirectory)\$(OutputPath)\*.dll">
      <Output TaskParameter="Include" ItemName="ModuleAssemblies" />
    </CreateItem>
    <CreateItem Include="$(MSBuildProjectDirectory)\$(OutputPath)\*.pdb">
      <Output TaskParameter="Include" ItemName="ModuleDebug" />
    </CreateItem>
    
    <!-- We copy all the project content files to our website directories. -->
    <Copy SourceFiles="@(Content)" 
          DestinationFiles="@(Content -> '$(DNNDirectory)\DesktopModules\$(ModuleFolder)\%(Identity)')" 
          SkipUnchangedFiles="true" />
    <Copy SourceFiles="@(ModuleAssemblies);@(ModuleDebug)" 
          DestinationFolder="$(DNNDirectory)\bin" />
  </Target>

Just open your project file in a text editor and add the above section just above the closing </Project> element.  You will also want to update the ModuleFolder and DNNDirectory properties for use with your particular project.  One of the benefits to this approach is that it becomes fairly easy to move the DNN site that I am targeting.  If a DNN site gets deleted, one little edit and I am back up and running on a new site.