Visual Studio 2008 – Issues with Compact Framework
Posted by Dan Vanderboom on December 9, 2007
I’ve been developing for the Compact Framework for over three years now, and the road has been long. So much is missing from CF that I have waited eagerly for v3.5 to arrive. So, in typical fashion, I downloaded Visual Studio 2008 on November 20th and was up and running with it soon after. The system I develop is distributed and highly complex, incorporating add-in modules, dependency injection, custom controls, MVC GUI patterns, SQL Server CE/Mobile, custom data synchronization, occassionally-offline behaviors, shared ORM data model across platforms, etc. At first glance, VS2008 looks good. It looks like VS2005 with a few subtle changes, but it’s familiar, faster, and seems (so far) more stable.
Windows Mobile 5 R2 SDK – Failed Install (Quietly)
Converting from the VS2005 to the VS2008 project file format was at first problematic. Though the installation didn’t error out, I got errors converting projects targeting Windows Mobile 5. When I switched them to Pocket PC 2003, they worked, but this wasn’t going to be an acceptable solution. I ended up uninstalling and then reinstalling the Windows Mobile 5 R2 SDK, and now I can successfully convert those projects. The worst part about this was that, although the projects seemed to upgrade, they couldn’t be read by Visual Studio, so they were unavailable in Solution Explorer. So it’s impossible through Visual Studio to change them back.
SQL Server Mobile – References Updated Automatically
Annoyingly, the conversion from VS2005 to VS2008 projects assumed that I wanted to use SQL Server Compact 3.5 instead of the SQL Server Mobile 3.0 database I was referencing previously. As much as I’d love to upgrade to the new database, and gain from improved performance as well as the ability to use the TOP keyword and use nested subqueries, our ORM tool is bound to v3.0. Not a big deal to find and correct that problem.
Confused Path to SQL Server Mobile
Adding a reference to SQL Mobile 3.0 on the .NET tab of the Add References dialog points to VS2005 directory by default… not a good idea. What happens when I uninstall VS2005? This assembly goes away and now my references are broken.
So I copied this directory:
C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\SQL Server\Mobile
… to a “ThirdParty” folder structure under “SQL Server Mobile” that we can reference instead. This folder gets shared and synchronized among developers.
I hoped it would have been easier to find, located in some shared place that makes sense. There is no “Mobile” folder here:
C:\Program Files\Microsoft Visual Studio 9.0\SmartDevices\SDK\SQL Server
… which is too bad. Though you’d think they’d put it somewhere like here instead, so it’s not VS folder dependent:
… or even in one of these places:
C:\Program Files\Microsoft SQL Server 2005 Mobile Edition
C:\Program Files\Microsoft SQL Server Compact Edition
C:\Program Files\Microsoft SDKs
… but it’s not. I think there is some great collective confusion at MS when it comes to organizing folder structures. How many SDK directories do you need, anyway?
Build Times – Scary at First, Now Fantastic
After one of the development machines kept getting 20 minute build times on a 20 project solution (when we had 4–7 minute build times in VS2005), we were on the gut-wrenching verge of reverting back to VS2005. But after some random tinkering, removing and re-adding references, and by deploying all add-in projects instead of referencing them from our entry point application, we were able to bring this down to about one minute. My laptop is a single core machine, and someone I work with has a dual core. Because of the hype I’ve read about 2008’s support for dual core builds, I expected his machine to beat the pants off of mine during builds. Such is not the case. I still build a bit faster, all other aspects of the machines being pretty comparable. One thing MS definitely got right was the F5 behavior. In VS2005, hitting F5 would rebuild our projects every time. Even if a project would occassionally not get built, MSBuild would still “process” the project for way too long. Now what we see is MSBuild activity bypassed altogether when a previous build succeeded and no changes have been made subsequently. This, along with the other performance improvements (and some unexplained voodoo), is saving us somewhere around an hour per day per developer. Note that the build behavior is not perfect yet. I still notice that projects that haven’t changed, and where no projects they depend on have changed, are still occassionally getting rebuilt for some reason. But it’s good enough, and certainly an improvement over what we had, and there’s a possibility that our projects have some buried dependency (I don’t pretend to be an expert in MSBuild).
Not Yet Compact Framework 3.5
Now that our system has been converted to VS2008 and we’ve been working in that environment for a few weeks, the next step is to upgrade from Compact Framework 2.0 to 3.5.
LINQ support in Compact Framework 3.5 deserves it’s own blog post.