Visual C++ for Devices Beta 1 features (and I'm a bad person who doesn't blog enough)

Okay, so I'm a bad person who doesn't blog enough. This entry has actually been mostly done for a couple of weeks now, but I haven't posted it because I wanted to review it, and then got caught up with various other issues. There are bound to be things in here that don't make a lot of sense, but if you send feedback I'll try to sort them out.

Our team has recently been going through the pain of figuring out what features are must haves for beta, and which features can be shipped with warts. Now that we've finished that exercise (and learned a lot of very interesting things that we never really counted on), I thought I had time to start blogging again.

So, for this release, all of our core features work reasonably well. You will run into some gotchas, and there are definitely some things that aren't intuitive, but for the most part, stuff works. One feature that has caused a fair amount of confusion internally and externally is deployment. In .NET Compact Framework (managed) projects, deployment options are stored per project, whereas in Visual C++ for Devices (native) projects deployment options are stored per configuration.

What does this mean when you are developing? In the tech previews and beta, you will need to individually set your deployment targets for each project (at the config level for native projects). This sounds really painful, but actually turns out not to be that bad for several reasons.

1) Native projects will default to a reasonable value for the current configuration. If you are targeting Smartphone 2003 (ARMV4), you will default to the Smartphone Device. We will default to the emulator if you are building for an Emulator or X86 target.

2) Managed projects only target one platform, so it’s likely that you won’t be switching between a very large number of devices.

3) Pocket PC Device and Smartphone Device both try the currently ActiveSync’d device when deploying, so you don’t actually need to switch between those.

One thing you might notice about deployment if you have used previous versions is that neither managed nor native projects block when deploying now. Oh come on, that’s totally worth a round of applause. I know that native also doesn’t block when you cancel deployment, I’m not sure how managed handles this scenario. Incidentally, the reason that we don’t block is that we don’t really cancel the deployment immediately; we simply set a flag to tell the worker thread that we are no longer interested in this deployment session. This means that you can have an outstanding cancelled deployment and start another deployment session. In this situation, if the new deployment session is targeting the same device that the outstanding session is we will block and wait for the outstanding session to complete (to the point that it can be cancelled). Why did we implement it this way? Because the emulator has a fairly slow boot time, and we can’t cancel midway through the boot in a clean way (TerminateProcess is not a clean method for canceling). This is something we’re going to try to fix eventually, but as always, results may vary. What makes this interesting is that after the outstanding session is cancelled, the other session will complete very quickly, as the emulator has already booted (i.e. we don’t trash all the work and start all over again, unless you actually shut down the emulator).

The wizards are probably the area that needs the most work done to them before shipping, there are going to be lots of small issues that may drive some of you nuts. Fortunately, most of these issues are fairly easy to fix, and you can manually tweak them.

PLEASE BACK UP YOUR WIZARDS BEFORE MAKING ANY CHANGES.

All Visual C++ for Devices application and code wizards are based on HTML and JScript, so they are open for your perusal. At the time that I’m writing this, the application (project) wizards reside in the <VC>\vcwizards\SmartDeviceAppWiz directory. Each subdirectory represents a class of wizards. ATL contains the ATL project wizard, MFC contains the Application, Control, and Library wizards, and Generic contains the Windows CE Application wizard (Win32 and Console apps for devices, effectively). Inside each wizard directory, there are four subdirectories, images, html, script, and templates. Images is basically images used in the wizards, you probably don’t want to change much here, unless you feel like looking at your own set of photos when you run app wizards. Knock yourself out. HTML contains a subdiretory named something like 1033 (the subdirectory is a locale-language code, 1033 is US English). This directory contains the page layouts, and simple scripts to set variables corresponding to selected options, and validate selections. Templates\1033 and scripts\1033 are the interesting directories. Templates contains (duh) templates to be used in the project. If you find yourself adding the same code to every project, you might want to put it into the template. Scripts contains a file named default.js that handles setting project options. Most of these should be fairly self-explanatory.

Developing for multiple platforms at the same time:

The most important thing to understand about solution configurations is that they don’t necessarily correspond to project level configurations. The solution configuration manager requires that each project in a solution have a configuration that corresponds to each solution level configuration (i.e. the matrix must be full). This doesn’t mean that each project has to support all platforms, just that if a project doesn’t support a configuration that exists in another project in the same solution, the solution configuration for that project will be mapped into an existing project configuration. As an example, imagine that you have a project with all of your business logic that supports Pocket PC 2003 (ARMV4 and Emulator) and also Smartphone 2003 (ARMV4 and Emulator) (call this project A). In the same solution, you add two other projects for user interfaces, which target Pocket PC 2003 (project B) and Smartphone 2003 (project C) respectively. Because the second and third projects don’t support all the platforms that the solution does, the solution configuration manager will point the solution level Smartphone configurations to the Pocket PC configurations in project B. Similarly, the solution level configurations for Pocket PC will point to the project level configurations for Smartphone in project C. At this point, the solution configuration manager evaluates the project and solution level configs, and determines that there is a mismatch between the apparent platform (what the config is displayed at) and the actual platform. At this point, the Build and Deploy options will be set to False for these configs. This means that if the current configuration is set to Debug | Pocket PC 2003 (ARMV4), when I build the solution, Project C will be skipped. You can re-enable building these configs by simply checking the Build and Deploy options in the configuration manager dialog.

When you have a solution with mixed platforms, VS will add additional configurations to your solution with a platform of “Mixed Platforms.” The Mixed Platforms configuration is most useful when you have mixed managed and native projects. Initially, the “Mixed Platforms” configuration will consist of the .NET compact framework, and one of your native project platforms. You can change the meaning of mixed platforms by pointing each at the desired project level config in the config manager dialog.

VCD projects support multiple platforms at the same time. When you create a project, there’s a platforms page in the wizard that you can use to set the platforms that will be included. You can also add platforms to a project after it’s been created. Open the Configuration Manager (Build/Configuration Manager, or click on either of the configuration dropdowns (the ones that display the platform and usually Debug|Release), and click Configuration Manager). The configuration manager will display the current solution configuration. Click on the “Active Solution Platform” dropdown, and choose “New…” Then select the platform you’d like to add, and make sure that “Also create new project platforms” is ticked. You can copy settings from <Default> or choose an existing platform. I’d recommend copying an existing platform’s settings, because it will make life much easier later on, when you have to individually tweak settings to get your project to compile.

Cheers!

Jeff Abraham
Visual Studio for Devices

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

• Anonymous
  May 26, 2004
  The comment has been removed