Fed Up With Project Versions
It's kind of a pain in the butt to have to compile stuff to two different versions of the Framework. I haven't dived into Whidbey too much, but I sure hope MSBuild lets you define which version of the Framework you want to target (I'm pretty sure it does, but I could be wrong). At any rate, I have to maintain two versions of my projects and solutions. It's kind of a pain to go through and edit my project and solution files after I'm finished with the 2003 version so I can compile in 2002, so I spent most of the night coming up with this solution: The VS.NET Version Commander.
Basically, what it does is, take a *.sln, *.vbproj, or *.csproj file, recognizes what version it is, and copies it to a new set of files, based on the settings in the “Options” dialog. Since Configuration.AppSettings is read only, I'm debating what the best way to store the program settings. I found a couple samples online that might help, but they're pretty complicated (go figure).
So, if you select a solution file, it will give you the option to convert each project in the solution (as shown). It will also go through and change any “3300” in the files to “5000”, and any reference to “1.0.3705” to “1.1.4322”. Finally, it will have the option of adding my “NET11” compilation directive to the VS.NET 2003 file, so that when it compiles, it picks up any places where I broke apart the functionality. Finally, it will let me save the per-project settings to a separate file for use later.
I'm leaving the door open to the possibilty of having it just convert single project files between versions, but this is really more of an internal tool, designed for the versioning processes that I have discussed many times in the past. Anyone that follows our guidelines for that stuff will probably find this useful.
I forgot how much fun it was to create WinForms apps. I think I'm getting the hang of threading. At any rate, expect this one to be online later in the week.