How to setup a DotNetNuke Development Environment with Source Control?

Question

My team is developing a new DotNetNuke web application and would like to know what is recommended to setup a development environment with source control and automated builds? We would like to keep the DNN source code separate from our custom modules and extensions source code.

The DotNetNuke Compiled Module template for Visual Studio wants us to store the source code in the DesktopModules directory of the DNN source code and output to the DNN source code bin directory. Is this the recommended structure? I would rather keep the files in different locations, but then it becomes more difficult to run and debug locally as it would require an install of the module for each change. Also, how should an automated build deploy any changes?

How have others set this up? Is there a recommended best practice?

Answer 1

We typically stick to keeping the module code in a folder under DesktopModules and building to the website's bin directory.

In source control, we just map the individual modules, rather than the entire website. Depending on what we're working on, a module may be an entire project in source control, or we may have multiple related modules in the same project, living next to each other.

Automatically deploying changes is somewhat difficult in DNN. It's highly recommended to have a build script that packages your module into an installable form. You can then copy installable packages into the website's Install/Module folder, and get the URL /Install/Install.aspx?mode=InstallResources, which will install any packages in that folder.

Answer 2

For my source control, I develop modules in their own project. This contains the module code, test code, data provider code (if applicable) and anything else. This is checked into source control like any other project. Note that the module project contains no links to a specific DNN website, and DNN references are made in the project to a common "bin" directory that references your target build. For example, in my projects folder, I have \bin460 , \bin480, \bin510, \bin520 etc. Each of these folders holds a set of binaries for a specific DNN version. That way you can build against a particular version but test against any version you like.

The problem with source-controlling a module in place in a dnn install is - sometimes not all of the module code is easily isolated under a single parent directory - doesn't lend well to a PA module approach - not easy to shift the project to a different DNN Version for development or testing - easy to inadvertently source control parts of the DNN solution, particularly with integrated VS source control solutions.

This approach compiles quickly because you're not trying to compile the entire project. For test deployment I have a build script that copies the various parts of the module into a target website. This can be done via the compile (link the build script) or just run after you've had a successful compile in a cmd window. My build script has a 'target' environment switch, so that I can say 'dnn520' to deploy the build to my test dnn520 install. Note that you need to manually create the module configuration first before this will work, but this is a one-time effort, and you can use the export feature to create your .dnn module manifest.

To build your module package, invest the time in a comprehensive script which will take the various parts from your source directory, and zip them into an install package. Keep all of the parts in your source control folder, and copy them into a temp directory, then run a command-line zip utility (I use an ancient version of pkzip) to pack it into an installable file.

The benefits of this approach is : - separation of module code from installed code - simple way of keeping only the module code in source control (don't have to exclude all the website code) - ability to quickly test out modules in different dnn versions - packaging script allows you to quickly and easily build a new version of a module for install testing/deployment

The drawbacks are - can't use the magic green 'go' button in VS (have to manually attach debugger) - more setup time than developing in-place

Answer 3

In response to bduke's answer. You should, and don't want to build projects in the DesktopModules folder.

1. That's where all of the source code for the site out of the box goes.
2. That's where you modules will be "installed" and thus if someone "updates" or re-installs one, then it will be overwritten
3. It can make upgrading your Application far more difficult. Many developers don't understand that the idea of not touching the original source code files to modify their behavior. BECAUSE it will just be overwritten when you perform an upgrade.

If you want to build modules, create a solution folder called Modules and place your seperate project modules there.

1. If you want to debug them, make the target debug output point to the web\bin folder.
2. If you want to install/deploy them. Build it in release mode and install them through the Module/Extension filter.