Deployment Madness in Compact Framework
Posted by Dan Vanderboom on December 13, 2007
This is a continuation of my article on Project Reference Oddness.
CAB vs. DLL Deployment
Back in Visual Studio 2005 (like that was a long time ago), I noticed an odd behavior with deployments of Compact Framework applications. Normally when you add a reference to a DLL, and you deploy that application, the DLL will be copied to the selected device, whether this is a real device or your emulator. In some cases, though, Visual Studio will deploy a CAB file. I searched high and low for a screen to give me visibility into this process, and hopefully for some settings to manipulate these behaviors, but I came up empty. Finally I broke down and scanned the contents of my entire hard drive for mentions of a particular DLL file, and I found the conmand_ds_package.xsl file hidden away in a little nook at:
I Googled parts of the path, the filename itself, and found nothing. (I see there are a few more hits out there now.)
It seems this file keeps track of registered CAB files, and the DLL files they contain. When you reference a DLL listed in this file, VIsual Studio will deploy the CAB file containing that DLL, instead of the DLL directly. In my case, I wanted to create my own CAB file that contained my application as well as all of its dependencies. It can be a pain to store and deploy a bunch of CAB files, and to install them in the correct order to avoid warning messages that scare end users.
If you’ve installed a third party library that registers its CAB files in this way and you would rather deploy the DLL files (which is also faster during debug-test cycles), simply go into this XML file and find the PACKAGE node that corresponds to the CAB file, and remove the entire PACKAGE. Do this carefully, however, and notice that some of these nodes can be fairly large.
Disclaimer: edit this file at your own risk. This is not a publicly documented area of Visual Studio. I wish it was, as I think building a tool around it to make it visible and manageable would be nice. But there you have it.
Bad Paths & Assumptions
I had Visual Studio 2005 installed on my laptop when I decided to install 2008. I knew I could run them side-by-side, and I wasn’t sure if Visual Studio 2008 was going to work 100% (shouldn’t assume), so I kept them both on for a while. After getting comfortable with the new version, I decided to uninstall VS2005. I thought I’d probably need to reinstall it at some point, but it’s been a little corrupt for a while (toolbox shows no icons, can’t view the designer for .aspx pages, etc.), and I was itching to remove it to prepare for a reinstall. The more I learn to depend on VS2008, the less I want to install the old version. But I ran into a situation today that really made me scratch my head.
It wouldn’t have come up at all, except that I occassionally like to wipe out a device (even cold booting it). I deployed an application to the device and got ready to fire up the debugger. During the deployment of the Symbol Mobility Developer Toolkit, though, I got an error that it couldn’t find a CAB file. (Yes, it was using the rule defined in the conman_ds_package.xsl file, mentioned above.) The output window told me that it looked in this location:
C:\Program Files\Microsoft Visual Studio 9.0\SmartDevices\SDK\Symbol Technologies\wce400\armv4
There was no such directory as Symbol Technologies in SDK. VS2008 and the 9.0 folder is very new, so there had never been such a folder, and I hadn’t installed the Symbol library for quite a while, so what could possibly be pointing to this location?
As I’ve questioned before, why on Earth would you want to store something like a third party library in a folder that is specific to one version of your programming IDE? This library is equally valuable to any version of the IDE, so it should be stored somewhere on its own… in some sort of Symbol folder, perhaps.
I decided to uninstall the Symbol library and reinstall, hoping it would reinstall itself into the new VS2008 folders for smart devices. To my dismay, I got an error message: “Unable to install SMDK – Visual Studio not found.” I guess VS2008 doesn’t count. The Symbol installer must look for that specific path.
The upside of this is that, by uninstalling the Symbol SMDK, those entries are no longer in the conman_ds_package.xsl file, and now Visual Studio just deploys the DLLs like I wanted it to anyway. For the Symbol library, this is okay. But for other third party components, you may really need the installer to go in. There may be supporting tools, such as external control designers. It sure would be nice if you as the developer had real control over all of these behaviors, instead of it being hidden away in undocumented files.
I ran across similar issues with SQL Server Mobile 3.0 and SQL Compact 3.5. First of all, converting projects from VS2005 to VS2008 seems to want to update your mobile SQL Server from 3.0 to 3.5. We use an object relational mapping (ORM) library called Extensible Persistent Objects (XPO) by DevExpress, a (for the most part) wonderful ORM that supports Compact Framework, and XPO seems to target 3.0 for the time being. When I wiped out my test device, SQL Server Mobile 3.0 disappeared, too. Then I tried deploying and instead of deploying that version of SQL Server Mobile, it just skipped that part, ran the application, and gave me an exception message: “Can’t find PInvoke DLL ‘sqlceme30.dll’.”
Why didn’t it deploy that CAB? Because VS2008 can’t find it. That CAB is located inside the Visual Studio 2005 Program Files folder.
This is what the folder structure looks like after you’ve uninstalled VS2005. Good thing some of those folders stick around instead of getting deleted! But really they should be elsewhere. When deploying the 3.5 version of SQL Server Compact, a much better source folder is used (under c:\Program Files\”):
Now that makes a little bit more sense, doesn’t it? Except… we have 2.0 and 3.5, but where is 3.0? Gosh, I just don’t get it. How odd!
So my advice to you is this: 1. Don’t try to make sense out of it. Just accept it and move on. 2. If you need to continue using SQL Server Mobile 3.0, deploy the CAB manually because Visual Studio 2008 doesn’t seem to want to.
Considering that the past few ranting articles are the result and reflections on a single day of development in the world of the Compact Framework, and also considering that this isn’t such an atypical day, this is why I sometimes laugh when companies underestimate the effort and explain that they might go ahead and tackle some CF project on their own. After all, their developers know the .NET Framework, so how different could the Compact Framework be? It’s just working with less memory and smaller screen sizes, right?
Good luck with that. More often than not, these projects fail horribly and they either find experts in the field or cancel the projects altogether. It’s too bad, because there’s a huge amount of potential with mobile devices. But the development experience is going to need to get a hell of a lot better before it really takes off. And Microsoft is going to have to make some pretty bold moves with competitors like Google handing out millions of dollars in prize money to develop on their Android mobile platform. But I have to say, the Silverlight on CF demos look very promising! Check it out: