Saturday, February 23, 2008 11:15 AM
We're currently gearing up to migrate from VS2005 to VS2008. I know what you're thinking, "What took you so long? VS2008 has been out for months!". Maybe true, but what makes this a bit tricky is that we're migrating an existing product during mid-development. Actually, we've just completed a beta release milestone so its not quite like we're stopping development in it's tracks, but we're still far from a completed product.
What drove this decision? Our product is a smart client application that currently uses a hybrid of Sync Services and SCOAB for offline/online synchronization. We've recently decided to remove all of the SCOAB components and go to a pure Sync Services architecture. As the vast majority of the application uses the SCOAB model right now, there will need to be a decent amount of new Sync Services code written. And, if you haven't seen it yet, I encourage you to check it out the Sync Services support in VS2008 because it's killer. We now have the capability to designer generate the majority of repeated code that we would either have to generate ourselves with a code generator or write by hand. Plus, we can also benefit from a lot of the ClickOnce improvements that came in VS2008 as well. ClickOnce is great but it starts to lose its luster when you deploy your client by ClickOnce, and then have to hand deploy redistributables for 5 other dependencies that your client requires which aren't ClickOnce friendly.
As you can imagine, this wasn't quite a "seamless" migration so I thought I would share some of the roadblocks that we've hit in hopes that it may help some other teams out along the way...
Web Services
We use web services for communication between our client layer and our business layer. Not only does this help to enforce the thin client nature of our product but it also sets us up well in the future to consider alternative clients to our business logic. However, we use WSE 3.0 to provide enhanced security for our web services. Apparently, VS2008 and WSE 3.0 do not play well together at all. In fact, it would seem that Microsoft has no plans on them ever playing well in the future. Their reasoning is that WCF can do everything that WSE can and more and that all new development should be against WCF. Although I agree with this, it was a bit of a roadblock that we hit with no warning. Unfortunately, when you "convert" your project from VS2005 to VS2008 with the wizard, it will "helpfully" regenerate all of your project web references with no WSE support. However, this can simply be worked around by hand copying all of your generated Reference.cs files from your VS2005 web reference folders to your VS2008 web reference folders. It's a bit tedious (some of our projects have over 50 web references) but actually works quite seamlessly once its complete. Strangely, the conversion wizard will retain your assembly references to WSE 3.0 so the copied WSE classes build fine.
MSTest Unit Test Projects
We have two MSTest unit testing projects in our solutions. You know, the ones that you get when choose "Test" project from the "Add a new project..." dialog. I have no idea how they got there and no one wants to admit that they added them. Regardless of their mysterious origins, the VS2008 solution conversion wizard is not a fan of them. In fact, it refuses to convert them altogether. This apparently goes back to one of the unit testing assembly references changing slightly which prevents the wizard from updating it when it converts the XML of the .csproj file. This is a known bug for Microsoft and they have issued guidance on how to hand edit the XML to update the reference manually. This is quite simple to do and can have you up and running in no time. This does work, but we chose to simply take the opportunity while we were buried knee deep in XML to remove all of the references to MSTest and just demote the project back to a standard class library. We were happier, VS2008 was happier, and I'm sure the project file was happier this way as well.
Though I will miss the the entire IDE locking up momentarily while it tried to load the unit testing toolbar if, god forbid, I accidentally clicked on the project in the Solution Explorer. That was always a nice savior from my train of thought and any hope of productivity.
I'm not pointing fingers (god knows I've released my share of bugs in my time) but I did find it odd that a bug that seems to affect nearly every MSTest project conversion made it all the way though testing and into release only to be found in the wild. Maybe Microsoft doesn't bother to user MSTest either...
Office Add-Ins
This is one we're still feeling our way through but here's what we know so far...
We have an Outlook add-in that ships with our product to support our CRM functionality. This is a quite simple add-in and doesn't provide as much additional functionality to Outlook as it enables communication between Outlook and our product. The SDK cocktail necessary to build this has always been a bit extreme and took us several tries to get right (Office 2003 SP1 and VSTO SE and Office 2003 PIA redistributable Oh My!). VS2008 has tighter support for Office add-ins built in automatically and, as such, has obsoleted the VSTO SE dependency for our needs. The upgrade, at least for Outlook projects, isn't quite seamless and may require some additional hand editing on your part though. On a slightly related note, the new VSTO Power Tools are well worth checking out if you do Office development. They obviously won't resolve your build errors, but they do look like they have the potential to help you through a lot of the pain points of building Office add-ins (such as keeping your development machine clean and figuring which parts of the SDK cocktail you still need).
Hopefully this well help some of you future whalers (I'm sincerely hoping that someone gets these whale references...) in your VS2005 to VS2008 journey. If you have any tips of your own, please feel free to leave them in the comments for all of our benefit. And good luck!