A major player in our very, very late delivery of version 2.3 of the Smart Device Framework turned out to be problems with toolbox integration in Visual Studio 2008. The process of automating the install itself isn’t well documented, so it took a while to determine that we weren’t actually doing anything wrong, but instead that we were uncovering bugs and limitations in Visual Studio itself.
There are two problems every CF developer needs to be aware of (and I really hope Microsoft will publish a KB article on these to help get the word out):
- Controls built against CF 2.0 will not show up in the toolbox for CF 3.5 projects. Period. There is absolutely no way to make them show up. So if you want your control to be available in the toolbox for CF 2.0 and CF 3.5 projects, you must build and deploy two versions of your control. This appears to be “by design,” though I’d argue a seriously flawed design.
- To compound the problems caused by #1, there is a serious bug as well. If your control uses the Microsoft.WindowsCE.Forms assembly, then you cannot add it to the CF 3.5 toolbox. The toolbox accepts CF 2.0 controls using it, but CF 3.5 controls will always throw an exception in Studio. Even worse, if you have several controls in a single assembly and just one of them uses Microsoft.WindowsCE.Forms, then none of the controls in the assembly can be added to the Toolbox.
So what does this mean to SDF users? Well nothing good. We first tried to work around “feature” #1 by building and deploying two SDF assemblies for our controls. It’s not very maintainable, and it’s painful, but we spent a good week getting our new automated build scripts to generate the necessary assemblies, CAB files and deployment manifests. After all that, we found bug #2, so even though we had the 3.5 assembly, it was unusable.
This means that, unless Microsoft releases changes to Visual Studio or we remove several controls from the SDF, you will not have Toolbox support for SDF controls with Compact Framework 3.5 projects in Studio 2008. We regret that fact and apologize to our users, but there’s simply nothing we can do about it at this point. What we may do (I’m not saying this *is* what will happen, only what we’re considering at this point) is split the OpenNETCF.Windows.Forms.dll assembly up to pull CF 3.5 Toolbox supportable controls out, but that’s going to break references and make deployment and nasty business.
So if you’re an SDF user and you’d like to use the SDF Controls in your CF 3.5 toolbox we encourage you to not open a bug with us, but instead open a support case with Microsoft. Remember, if you open a case with them and it turns out to be a bug, the support incident is free. What it does, however, is give them some insight into the number of customers that the bugs actually affect, and hopefully will give them some incentive to release a fix for these problems before 2010.
Note: One semi-kludgy way to get the Controls to show up is to start the project as a 2.0 project and drop them on the Form, then upgrade the project to 3.5. It seems that the designer itself can handle the objects, it’s just that the Toolbox can’t.