I am again traveling this week, in Toronto speaking at Tech Days Canada 2009, and as luck would have it I needed to complete some work on a few custom DotNetNuke modules for clients on an "Urgent" basis. So this afternoon I darted off to the speaker room to get an internet connection, just recently I reformatted my laptop to move to Windows 7, one of the main reasons that I needed to re-format the system was to create an environment that matched my primary development machine, today was the first true test of this new configuration. Thankfully everything worked as expected and all issues were resolved. In this blog post, I'll explain a bit as to why it is important when working on multiple environments to have consistent system configurations.
What Must Match?
The first question that is most likely going through your mind at the moment is: what items must be "consistent'? Well, my personal recommendation is as much as possible. For example the Visual Studio Version, DNN installation location, Module working paths, DNN Versions, and other related folders that might be necessary.
In the case of my modules, each has a build file that creates an installation folder for me, since I have yet to move to MSBuild the paths are hardcoded, referencing my folder structure on my primary machine. Builds on that machine all go to my D: drive and on my laptop prior to the re-install I didn't have a D: drive at all.
So Why Do You Care?
The key point of this exercise is why do I care? Well this is very simple if all of the above items match from one system to another, it is possible to simply open your source control system, do a "get the latest version" and you can instantly change files and only worry about checking in changes. If you have environment differences, say for referenced DLL's, or build paths, it might be possible to need to modify files that normally wouldn't be changed, then if you check those in, you wind up breaking your existing development environment.
This is an important thing when working on projects with one developer and multiple machines, as well as when working with multiple developers on the same project. Establishing a consistent development configuration will help you avoid hassles and problems that can arise from different file paths and references.