At work, my project is preparing to release the current version of our application to the clients. This release will is still in version 1.1 of the .NET framework, but we will be converting up to version 2.0 for the next phases of our development. To accommodate the ongoing support effort of the impending release (we will be supporting this for the next 8 months or so) we have split the source code into two branches. In theory we will be merging all changes from the support and maintenance branch (.NET 1.1) up to the new development branch (.NET 2.0) on a regular basis.
In a spot of uncommon preplanning, I decided that we should give this process a go before we get to far in and have no easy way out. I worked with the development branch to get it converted up to .NET 2.0 and, a couple of days later, proceeded to merge the changes from the support and maintenance branch into the now converted code. Things went to the crapper in a hurry. The biggest problem that I encountered was in the merging of the project files. The VS2k3 and VS2k5 project file structures are significantly different and the merge process was completely overwriting the project files in the .NET 2.0 branch. Not a good thing, as we're going to be adding files to those projects in the development branch and the merge was also converting the project files back to the .NET 1.1 format which caused the project to want upgrade every time we opened the solution.
Another thing that happened related to the changes in the web project styles that occurred between v1.1 and v2.0 of the framework. In v1.1 there was a *.csproj file for any web project that you create, but in v2.0 it disappeared until you installed the Web Project upgrade (not an option for us as this would take months of bureaucratic processing to see it actually end up on the developer workstations). When you merge a web project from a v1.1 branch into a v2.0 branch it will add the *.csproj file back to the directory. This results in another attempt by the IDE to convert the web project from .NET 1.1 to .NET 2.0.
I haven't figured out a smooth way to merge these files, so I started coding. I've almost completed a tool that will parse solution and project file structures, for both versions of the framework, and output a text report that displays the differences between the files. One of the more difficult things to deal with has been the removal of a project file for web projects. I rely on that file to be able to determine what is, or isn't, in the project. Without it, it's very difficult to perform a proper and complete comparison of that project type. Additionally, the movement of the code behind files from being co-located with their partner *.aspx or *.asmx files to their own App_Code folder. A little creative coding and this can be resolved, but it's an extra layer of complexity that isn't necessarily desired.
Overall, I'd say the experiment sucks. Unfortunately our client and management has decide that the framework upgrade is too risky to perform prior to our once again deadline missing project. Not only that, but management wants to continue to add new features to the Phase 1 release while it is in maintenance mode and while we are working on the new development of Phase 2. So instead of just merging up bug fixes that are found in production, we will now be merging up bug fixes and new functionality. Nothing like adding a little complexity to the situation to add risk to, and decrease the quality of, the next major release. I'm just glad I'm not a tester. In the end it will be the fault of the developers. It always seems to be. I guess it's my job to stop that from happening.
posted @ Wednesday, December 27, 2006 8:19 PM