If you're familiar with the source code of the DNN Platform, you probably agree with me that it is not easy to set up for development purposes. And you'll probably agree with me that it is not entirely clear how to build. Or even what build does. Just so you know: we are working to improve this. If only to make our own lvies easier developing DNN.
Recently the "Admin Experience" project was folded into the main DNN Platform project. If you're thinking "what's this admin experience"? It's the PersonaBar. Until recently it was a separate project in its own repository. This made developing and improving features difficult as your code would likely span two seperate repositories on Github and you'd be juggling pull requests that depend on each other. So this move was designed to make development easier.
Today another change was integrated: a new package build process. After the merge of the two main repositories we hadn't yet fully resolved how to build this one unified project into release zip files that you guys are used to download. Until now this process was largely based on MSBuild. In the past Oliver Hine and Andrew Hoefling have worked on a first move to Cake. This is a relatively new technology (like DNN backed by the .net foundation) which allows us to script builds using C# scripts. We feel that it is a good bet for our future build technology.
There are roughly 5 steps to building DNN's familiar release zip files:
- Copy the result of compilation (dlls) and any static files from the project over to a folder which will be used to zip up (./Website)
- Package the various parts that are distributed as extensions into their own zip files and copy those zip files over to the aforementioned folder
- Download and compile (if relevant) external projects and (much like #3) zip up and copy to the packaging folder
- Zip that folder into a zip file ensuring to leave out any files that shouldn't be there
1. Move all source controlled static files from ./Website to ./Dnn Platform/Website. This addresses an ambiguity in the role these folders play given that the name is the same. The latter was used for a few static files, while the former held the bulk of them. Now all source is in the latter and the former is *only* used to copy into during the build process and is not under source control.
2. Replace MSBuild with Cake for step #5 above. I.e. the packaging of DNN is now done using Cake rather than MSBuild. The old (MSBuild) scripts have grown with the solution over the years and suffer from the same as many other parts: they are confusing and contain dead code. And this made chasing down errors difficult. So it is now a completely new script that drives this part.
3. Merge the Admin Experience build scripts with the platform build scripts. The AE project had a set of scripts that were cloned from the main project a long time ago and then tweaked. The current solution now has just one directory with the main MSBuild scripts: ./Build/BuildScripts
The long term strategy is to clean up the old MSBuild scripts even more. We are still far from an easy to understand build process. But we did make progress today. We also will now be able to focus on improving the mechanism with which developers can create a working development version of DNN locally. I.e. the ability to run the DNN source code on your own machine so you can more easily make changes.
I want to thank Brian Dukes, Daniel Valadas and David Poindexter who've invested time with me on this.