Microsoft recently released Visual Studio 2008 Beta 2 (http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx). Being the type of developer who is always interested in such tools and more importantly currently being involved in a couple Windows Presentation Foundation 3.0 projects I was one of the first to download a copy. One of the new features of Visual Studio is that it allows you to target your builds at the .NET 2.0, .NET 3.0 or .NET 3.5 versions of the .NET Framework.
My expectation although the documentation doesn’t claim it, is that I would be able to start using VS 2008 while other members of my team continued to use the older Visual Studio 2005 with the November 2006 CTP extensions for WPF support. I was partially (mostly in fact) correct – but it requires a few ‘tricks’, and more importantly even for true .NET 2.0 projects that isn’t a true statement.
The warning shot was fired when I opened the project solution. The first thing that VS 2008 did was initiate a conversion wizard to convert the solution and project files on the project. It kept them targeting .NET 3.0, but they would no longer open in VS 2005. Fortunately I hadn’t checked anything into TFS so I copied the files and undid my changes. (Note: I later tested with .NET 2.0 projects and the result is the same. There is actually a reason or arguable merit for this, as I’ll explain as I discuss how to manage this scenario.)
So what I then did was take my solution and project files which I had converted and copied out and named them with the original project name plus “2008” on the end. This meant I still had the original project files and the newly converted files. In comparing these files it was apparent the scope of differences was minimal – in fact it was mainly a couple strings to reflect that these were in fact 2008 versions of the same file. So I modified the solution file and instead of referencing the projects in the solution by their original name I adjusted the solution file references to be the other “2008” versions of my project files.
I then reopened my new solution file in Visual Studio 2008 and found that my solution would build and was maintainable. In fact I was able to work in this mode quite literally for a couple of weeks with no issues what so ever. It then came time to package this project for deployment. We were using a Click Once deployment model and this is where two issues were discovered. The first issue was that Visual Studio 2008 Beta 2 did not include a signed .NET 3.0 Framework redistributable package that you can add as a dependency to your project. There wasn’t much to be done about this but I did mention it along with my other problem to Microsoft.
The second issue was that while in the project properties, if I clicked on the Security tab, Visual Studio 2008 crashed. Not threw an error - it crashed and burned. As part of being a Microsoft MVP I have access to a shortcut for contacting a couple people on the development team about issues when I’m working with something like VS 2008 Beta 2. In this case I mentioned my concerns about having new project types, my concern with the .NET 3.0 redistributable and my issue with the Security Tab for my project’s properties causing Visual Studio 2008 to crash. This got the attention of Eric.Knox one of the ‘developers’ @Microsoft who emailed me about reproducing the problem. Because the customer was comfortable with me sending this problem to Microsoft I forwarded Eric a complete copy of my solution files (fortunately it was a relatively small code base).
Eric was immediately able to reproduce my problem (which was good) since I was now bothering someone who's time is arguably more valuable writing new features into the product J. After a couple hours Eric contacted me to tell me what the problem was. In short when I readdressed my solution file to reference my project files, I failed to also adjust the project references in my project files to do the same thing. For most of Visual Studio this wasn’t a problem, but in the case of the security tab this caused a fatal error. Eric was able based on my code to find this in a relatively short period of time – and in the RTM version of Visual Studio 2008 the environment won’t crash if you repeat my mistake. At the same time however, this is still an error in Visual Studio 2008 and the error message you get may not be the most helpful.
The key is you need to be certain to convert the project references in both your solution and project files if you want to develop on Visual Studio 2008 in parallel with someone using Visual Studio 2005. Aside from the preceding issue I’ve had only one issue (that I’m about to discuss) working this way, and being able to work in Visual Studio 2008 has made me far more productive then I would have been with the Visual Studio 2005 environment and the XAML editor which is almost non-functional (for complex XAML). In general I’ve just manually added new classes placed in the Visual Studio 2005 versions of the project files to mine and vice versa. The coordination on that level has been very easy and relatively painless – so if you are in the scenario where not everyone on a team is in a position to move to Visual Studio 2008 simultaneously, I’d still go for it on .NET 3.0 projects.
However, there is the remaining issue which appears to coincide with the reason Microsoft is moving the project files forward. I stumbled on this issue quite by accident when during development I created a new class in the project. As part of this new class I happened to syntax which is based on the new release. I didn’t reference any .NET 3.5 libraries but I wrote my VB/C# code using syntax which the Visual Studio 2008 compiler recognized. However, Visual Studio 2005 and Visual Studio 2008 don’t use the same build engines and as a result when a team member tried to compile my new class the compiler kicked out my code. So if you are going to attempt this route recognize that although you are still building a .NET 2.0 compatible project (based on the libraries which are referenced) you will have access to language features that are interpreted by the compiler at build time which aren’t compatible with the build engine a Visual Studio 2005 developer will use. Again this wasn’t a major problem, in fact it was incredibly easy to recognize and resolve but this is probably the type of issue that the folks at Microsoft were most concerned with when they made it so that the same project file wouldn’t work in both build environments.
Finally of note, keep in mind that a new version of TFS (TFS 2008) will be shipping with Visual Studio 2008 along with a new version of Team Build. Both have several new features that you’ll want to access and since your old Team Build 2005 won’t like Visual Studio 2008 projects – you’ll need to upgrade to TFS 2008 in conjunction with or before you move your developers to Visual Studio 2008, so make sure you start looking at that Beta 2 product now as well.
