How should deployment work in VC++ for Devices?
Hey, given the great feedback we got from Josh's new project questions, we're going to pose another question to you: How do you want deployment to work in VC++ for Devices?
As those of you who have gotten your hands on early versions have no doubt noticed, deployment can be interesting. It gets even more interesting when you look at the multiple project case. Currently, each project's deployment target is set independently, and is set per configuration. We differ from the VC#/VB.NET team in this respect, as they set deployment targets per project (boo!!). Why do we set deployment targets per config? Because we couldn't really think of a scenario in which you would want to have X86 bits deploy to an ARMV4 device. In VCD projects, the configuration loosely implies the target. To save you from having to change the deployment target when you switched target platforms, we made this property per configuration. Before we go any further, I'd also like to point out that unless you explicitly set a device, you will have one picked for you that best matches your current configuration. This is the “default“ device.
Assume that we have five VCD projects, A, B, C, D and E in the same solution. A depends on B, which depends on C and D. There is no dependency between C and D, and there are no dependencies between E and any other projects in the solution. Quick terminology: A is “upstream“ of B, C and D because it is dependent on them; B is “upstream“ of C and D. The meaning of “downstream“ is left as an exercise for the reader. If I change the deployment target in A, should the deployment target be changed in the projects that < are in the solution | A is dependent on>?
There are a few options for this:
1) Current implementation: Don't change anything other than A's deployment target. Users must set each deployment target explicitly. We don't particularly like this solution because it requires a lot of visits to the property pages to change deployment targets.
2) Change everything. All projects in the solution will have their deployment target set to A's new deployment target. This is probably better than 1), because it requires less visits to the property pages, but doesn't allow you to have multiple projects in the solution deploy to different targets. If A is changed, B, C, D and E all change.
3) Change only projects downstream of A, e.g. in this case B, C and D. E would not change. In this case, if I changed the deployment target in B, the deployment target would be changed in C and D, but would not be changed in A or E.
4) Change projects upstream and downstream of A, i.e. change any projects that we are dependent on, or that are dependent on us. In this example, A, B, C and D would all change, regardless of which project you changed the configuration in. E would not change.
5) Change projects downstream of A that are currently set to deploy to the same device as A was originally, or that were set to deploy to the default device for their configuration. This is an interesting solution, because it allows you to do things like set D (which could be a web server project) to deploy to one Windows CE device, and have A, B and C deployed to another device which hits that web server. Then you could change your deployment device for A, B, and C without having to change D manually. Of course, this is potentially confusing, because it changes some projects, and not others.
6) Change projects upstream and downstream of A, i.e. change any projects that we are dependent on, or that are dependent on us, that are currently set to deploy to the same device as A was originally, or that were set to deploy to the default device for their configuration. See comments for 5 for an explanation of why I think this is kind of neat.
Nishan (our program manager) and I are leaning toward implementing 3, 4, 5, or 6. Given an infinite number of monkeys developers we could implement all of these and let the user decide which was appropriate per solution. Of course, we haven't budgeted for infinite monkeys developers, and I kind of enjoy seeing the outside world every now and again, so we'd like to know what you think is appropriate, and we'll try to implement that.
Thanks,
Jeff Abraham
Visual Studio for Devices
This posting is provided "AS IS" with no warranties, and confers no rights.