The majority of developers who see this blog are probably use to collaborating with other developers on projects. However, many developers who have spent only a limited amount of time on DotNetNuke development may find the process somewhat overwhelming. This is because even though DotNetNuke is an ASP.NET application, it is a specific framework with its own API. As with other frameworks, sometimes only experience or the view point of someone with experience can permit you to identify common problems before they occur. While the team here at AppTheory cannot say we have seen it all, as something new always pops up, we have plenty of experience with development team collaboration and DotNetNuke. In an effort to share some of our experiences, I have put together some of best practices we find vital to a successful project.

Because this can be a rather broad topic, I will be publishing a series of blogs each referencing a more specific area within the topic. This first installment will be dedicated to the development environment. One thing you should keep in mind when reading these blog posts is the target audience of the blog series is for those developers who are collaborating on a live site installation and NOT developers who are selling 'boxed product' modules or providers to other developers. The 'boxed product' developers will unlikely be able to access live data, live installations, nor will it be easy for them to mimic all the various development environments in use.

The first hurdle when it comes to any type of development collaboration is ensuring that everyone is working with the same basic set of tools and base installation Doing so will decrease the time spent tracking down environmental variables. While I understand that some of this is a matter of personal preference, it should serve as a good guideline for creating your own policy to get your organizations collaborating efficiently. Below I am breaking things down into a bulleted list trying to explain the purpose of each item. 

• Tools:
  • Development IDE: Mixing development IDE's between teams is adding another layer of concern as well as administration if you are doing anything with automated builds. (Visual Studio: 2003, 2005, 2008)
    • If you are using the Web Application Project (aka WAP) type as we do (because of deployment reasons), mixing Visual Studio 2005 SP1 with any Express edition prior to 2008 SP1 will result in a nightmare because those Express editions do not support the WAP model. (* If doing this, you will receive a message in the Express edition stating it is not a supported project type)
    • Likewise, as you probably guessed, you should be running the same service pack update as well as major version of Visual Studio if possible. (* You could support different Visual Studio versions, although I do not recommend it, if using 2005 and 2008. You just have to have separate solution files and ensure the same target framework is being used.)
  • .NET Framework Version: Prior to Visual Studio 2008 this probably went without saying. (1.1, 2.0, 3.5, etc.)
    • However, with Visual Studio 2008 came the ability to target which version of .NET you will be compiling your application against.
  • Source Control: Naturally, you will need a single source control server that all parties have access to. (Subversion, Vault, TFS, etc.)
    • Don't forget the client! Make sure all parties have the same client application installed to access the source control server. (* If using Source Gear's Vault, it has always been a requirement to use a specific version of a client with a specific version of the server. Using Subversion and Tortoise, I have not seen a need to keep all client versions identical unless there was a major version release.)
    • The actual DotNetNuke install should be under source control, however, it should rarely ever require changes. You should also keep all assemblies that should never change such as providers, http modules, or framework items in the root bin. (* Basically, anything required to run the DotNetNuke framework or any entries in the web.config that would be required to run the site.)
    • If you are collaborating with multiple teams, or using multiple repositories, you should implement a standard folder structure as well as naming convention.
  • Database Server: Microsoft SQL Server version. (2000, 2005, 2008)
    • All developers should locally use whichever version of SQL Server they are targeting in production. Because of differences in permitted data types, this is going to be much increasingly important once 2008 is involved. We typically use 2005 at this time. One note here is that if using 2005, I haven't seen a problem mixing the Express with Developer or Enterprise Editions.
  • Web Server: You can have some variance here. IIS 6 & 7 are, for the most part, very similar and can both be used so long as you have the web.config properly setup. (IIS, Cassini)
    • If you are using the built in ASP.NET web server that comes with Visual Studio, formerly Cassini, you may not one to mix that server with other developers using IIS. I personally recommend using whatever mimics production if possible.
  • Build Server: While I don't want this post to focus on Continuous Integration, CI, I would not feel comfortable mentioning "Best Practices" without it. (CCNET, DracoNET, TFS, etc.)
    • I would recommend that all teams that are collaborating on a project implement the CI process, especially build notifications. These notifications help identify, early on, a problem that needs to be resolved by the developer who broke the build. Please do keep in mind, a successful build still can result in deployment problems later on.
    • If you are using nAnt on your build server, you should also make this a required tool for your developers. MSBuild will be available after Visual Studio is installed. You should also keep a copy of all build related files under source control so it can be access by all developers involved.
• Data:
  • What to Start with: You have to chose to start with a clean database or a copy of the production database adjusted with a local Portal Alias.
    • This one will vary on a case by case basis. Sometimes you just need a copy of production data when tracking down a certain bug, or you are working on a DotNetNuke base version upgrade. In most cases, you should be capable of working on clean databases you create locally. (* In instances where you sometimes need to work with a database populated with production data, you should keep a copy of this under source control.)
    • While not always necessary, it isn't a bad idea to have a standardized naming convention for the database names and also agree on common {objectQualifier}'s as well as {databaseOwner}'s.
    • Keep in mind, when using production copy of data you should also consider having ALL necessary files to run the site under source control including skins to avoid errors in running the site. (* NOTE: Anything that should be built by the developer in the bin should NOT be under source control and built on the development machine as necessary.)
• Configuration:
  • Building: Even if you are not using a build server, you may wish to use automated packaging.
    • If you are using anything to automate packaging or deployment, all developers should locally 'deploy' things using these tools to ensure when it comes time to install no new errors will be found during the installation process. Automated packaging should save developers time and should help remove human error from the process.
  • Web.Config: Keep a copy of this file saved as Web.Config.Default under source control.
    • This lowers setup time and helps avoid environmental variables such as a missing httpmodule. When a new developer joins the team, they simply should be able to rename this file to Web.Config (which you shouldn't keep under source control) and simply change the connection strings to get going provided they have the database setup.
  • Design: Skins & Containers may be required to be under source control when using a production copy of the database.
    • You may wish to keep source files like psd's and installable skin packages under source as well to ensure quick deployment to multiple servers/workstations.
  • 3rd Party Dependencies: References can cause a nightmare for new developers without proper organization.
    • If you use 3rd party components/tools such as those provided by Telerik or EntitySpaces, all references used in custom projects should be located in a centralized folder under source control per DotNetNuke installation that is NOT the web bin directory. We typically reference items in a custom folder under Library\AT\.
    • Another note to keep in mind, limit project references and instead use assembly ones when possible. If you don't plan on deploying the assembly with your module or provider, it's a good idea to use an assembly reference.
  • Portal Alias: Even if you are not sharing a database or using a copy of production, a standard naming convention should be in place.
    • We typically like to use the name of the folder containing the DotNetNuke install. (ex: localhost/MySourceWebsiteFolder)

The above list is really the foundation of collaborative development when working with DotNetNuke. It doesn't really touch on programming or deployment specifics. However, if a policy is in place that covers most of the items above you should find the time it takes for new developers joining the team to become acclimated with the process as somewhat limited. In the next installment, I plan to discuss the SqlDataProvider.