As long-time DotNetNuke users well know, DotNetNuke contains an extensive API that makes the platform extremely powerful and flexible.  Over time the core APIs have continued to expand as new features were added and existing features were enhanced.  One of the core APIs which has been part of DotNetNuke since 4.6 was released three years ago today is the XML Merge API.

The XML Merge API was developed to enable developers to define changes that need to occur to any xml based file within the website.  It is primarily used by the core framework to make updates to web.config but has utility beyond just updating web.config.  Web.config management was a huge problem in early versions of DotNetNuke.  Managing and applying the web.config changes every time you upgraded DotNetNuke was a time-consuming and error-prone process.  The XML Merge API was developed in part to address this need.

When I first created the API, I needed a way to merge dozens of custom URL rewriter rules into the siteurls.config for the AspDotNetStorefront module.  These rules could change with new versions of the ASPDNSF module and so I also needed to support the ability to apply these changes in a version specific manner.  My first version was included as part of the ASPDNSF module, but due to a contractual arrangement, I was able to make this API available in DotNetNuke as well.

DotNetNuke recently moved to an Open Repository that is hosted on CodePlex.  As Phil Beadle recently noted, the synchronization process is now fully operational and is running nightly to ensure that the CodePlex repository mirrors our internal version control system.  Of course, having access to the source code and understanding how to use the source code to get to a working build is two different things.  The source code package that we deliver with each release is slightly modified from our own internal repository in order to minimize confusion for the community.  Over the years the core team has become accustomed to these steps, but for new people, getting DotNetNuke up and running from source code can be a bit daunting.  Hopefully I can help dispel the mystery and make it a little easier to understand why DotNetNuke source code is packaged in this manner.

NOTE:  For the remainder of this post I will assume that you are familiar with DotNetNuke and that your system is already configured.  The source code version of is not intended for people who are just getting started with DotNetNuke.  If you fall into this category then I would recommend starting with one of the install packages to better acquaint yourself with DotNetNuke.  If you use the install version with the Web Platform Installer, then it will ensure you have all the necessary pre-requisites installed.  For more information on installing DotNetNuke you should review the Installation Instructions or watch the Installation Webinar which are available on the downloads page.

The last 7 years has been a very exciting time for the DotNetNuke team.  This period has been marked by constant change.  Sometimes the changes were positive and helped move the project forward, and other times the changes did not achieve the desired results and thus became a learning opportunity.  During this period we have had almost 80 core team members and project leads, had 5 major releases, hosted the project on 3 different open source websites, had 3 different project forums, and used 3 different source code management systems (hat tip to the reader who can name the websites and SCMs) .  We have also launched a company, created a commercial version of the project, and hosted conferences in North America and Europe.  All in all, it has been a pretty busy time, marked by lots of changes.  There have been 3 constants throughout the life of the project – Shaun Walker has always been the leader of the project, DotNetNuke has always been offered under a BSD open source license (we’ll conveniently ignore Shaun’s brief flirtation with a different license in 2003), and we have always operated a closed repository.  Today I am happy to announce that one of those is changing.

The DotNetNuke project, with the release of DNN 5.0 and DNN 4.9.1, officially moved our project downloads to CodePlex. There were some questions in the DotNetNuke Forums about this and when my response started growing, I thought I would blog about it instead.

To address some specific questions:

Q:  Was this an impulsive decision? 
A:  This is something that has been in planning for many months and was not something done out of impulse. 

Q:  How do I find all of the related projects on CodePlex?  All the downloads were available on the same page at SourceForge.
A:  If you look on the DotNetNuke page on CodePlex, all of the other official DNN projects are listed.  You can also click on the DotNetNuke tag in the tag cloud (visible on the CodePlex homepage) to see a complete list of all DotNetNuke related projects on CodePlex (there are currently 88 listed). 

Q:  Are all of the core projects on CodePlex?
A:  Yes.  Scott Willhite and Shaun Walker worked with the CodePlex team to move over all of the official DNN Projects.  Not only did they move the project downloads, but they also moved the project’s historical data as well.  In addition, since CodePlex is also the official Forge repository, all past and future projects created from the DotNetNuke Forge will also show up on CodePlex.  So now we will have all of our projects consolidated in one spot.  There will still be some community projects which choose to use other repositories, but over time, you will see CodePlex becoming the first place people look for Open Source DotNetNuke related projects.