Insight into VC++ for Devices - Solution level platforms, settings, deployment toolbar
Given that I helped to ship Visual C++ for Devices (VCD) to an unsuspecting development community, it seems only right that I should help to clear up some of the issues that are likely to impact our customers (plus some of these random tidbits are interesting to me).
Solution level platforms don't necessarily equal project level platforms (or: Why is my Pocket PC config building for Smartphone?)
One of the interesting issues about VS is the way solution configurations interact with project configurations. I have Project 1 with two project level platforms, PA and PB (I'm not typing out real platform names in the interests of my sanity. For clarity, I will assume that all projects only have "Debug" configurations, but that's just to make life easier for me, and doesn't particularly affect the example). I also have Solution 1 that contains Project 1, and it has two solution level platforms, which will mysteriously be called SA and SB. This is a fairly normal case. Now I want to add Project 2 to my solution. Project 2 has three project level platforms, PA, PB, and a new project level platform PC. When Project 2 is added to Solution 1, Solution 1 dynamically creates a new solution level platform, SC so that it has a full matrix (a solution must contain a solution level platform for each project level platform contained in the projects present in that solution). The interesting question that now arises is what happens in Project 1? The answer is that the solution configuration manager will pick a platform from Project 1, and set that to be the associated project level platform for the missing platform. This means our configuration mapping table ends up looking like:
| Solution Configuration | Project 1 Configuration | Project 2 Configuration |
|---|---|---|
| SA | PA | PA |
| SB | PB | PB |
| SC | PA | PC |
Hopefully that table looks reasonable, I'm having issues with the rich edit control on the web page at the moment.
The upshot of all of this is that if you start having strange issues after adding a project to a solution, look to see what the solution configuration manager has done with the mapping (in the configuration dropdown, choose Configuration Manager. You can also get to a slightly different version of the config manager by choosing Solution Properties, Configuration Properties).
Settings and where settings trust funds come from...
Excellent question, where aren't they stored? There's a hierarchy of settings for VC projects. Truth be told, there really aren't project level settings per se, all settings are stored in the configuration (or lower) settings collections. Let's take the example of compiling a source file, because that's the easiest way to imagine this. When the compiler tool within the VC project system (e.g. the wrapper for CL.exe, VCCLCompilerTool) is called, it's typically to generate a command line. VCCLCompilerTool first checks to see if there are any file level configurations for the current file, and if there are any settings for the compiler tool in those. If so, those settings will be used. If there isn't a setting available at that level, VCCLCompilerTool will fall back to checking the configuration for settings. If there isn't a setting available at that level, VCCLCompilerTool will fall back to checking the any property sheets, and failing that, use the tool default. There are some properties that have the property of inheriting from the larger settings groups, for example preprocessor definitions. If I have a file level configuration on MyFile.cpp, any preprocessor definitions I set on the file configuration will be joined with the configuration, property sheet, and default preprocessor definitions to form the set of all preprocessor definitions, and when that file is compiled, it will have all definitions (you can change this inheritance behaviour, look up $(NoInherit) in the VC documentation).
The deployment toolbar is greyed out...
Okay, this is a bit of a weird one. Typically people see this problem when they're migrating eVC projects. The deployment toolbar is actually implemented as a completely separate bit of code (actually in a VS service) than the VCD project system, and is shared between VCD and that whole "managed" code team, who work on itty-bitty device support for obscure languages like C# and VB.NET. Or so I'm told. Anyways, language wars aside, when your project is loaded, the VCD deployment tool is created if there are any settings that should be handled by it (VC in general does lazy initialization and has stateless tools for performance reasons). If there isn't a deployment device, we will set a default device based on the closest match found. If a deployment device is set (by default or explicitly), then the VCD deployment tool will call into the deployment toolbar and register itself as a hierarchy to be notified if and when the deployment toolbar setting is changed. Why does this matter? Well, this matters because unless the VCD deployment tool is initialized, the deployment toolbar will never be initialized, and will always be greyed out. How do you work around this? Simple, ensure that the VCD deployment tool is initialized by opening the property pages and navigating to "Deployment."
That's it for this post, I'll attempt to post again soon with more random tidbits. Feel free to ask if there are any issues you're having with the IDE or you want to know why we did something in a particular way.