Configuration management

[nguerrera]

Today, VS still relies on parsing magic $(Configuration)|$(Platform) conditions. To bootstrap, we have these for Debug|AnyCPU and Release|AnyCPU in our props, but that means that the user cannot remove AnyCPU configurations and needs to manually add other configurations with these magic property groups which are quite out of place in our leaner project files.

We need a simpler way to define the valid set of configurations.

Proposal

1. Replace the magic conditions in property group with two new properties
   $(Configurations)- lists the set of valid configurations, default will be Debug;Release
$(Platforms) - lists the set of valid platforms, default will be AnyCPU

These are analagous to $(TargetFrameworks) vs. $(TargetFramework) except that any given build will build only one combination, there will be no auto-batching at the msbuild level over all configurations and platforms.

2. Validate that $(Configuration) is one of $(Configurations), $(Platform) is one of $(Platforms) and $(TargetFramework) is one of $(TargetFrameworks).

This replaces the validation that we gave up where and invalid Configuration|Platform combination was observed by the lack of an OutputPath. We want the user to say what configurations they want without having to say the OutputPath for each, which we can define for them.

3. Change VS project system to enumerate configurations and platform dimensions like it does for
   TargetFrameworks and stop parsing the magic conditions. Configuration management project-system#694

[rainersigwald]

@kzu just mentioned this morning that it'd be nice to have this in an item like ProjectConfigurationsDeclaredAsItems or vcxproj's ProjectConfiguration.

[nguerrera]

@rainersigwald Interesting. Seems like those are basically referring to the same thing with ProjectConfigurationsDeclaredAsItems referring to capability for CPS to load configurations from ProjectConfiguration items, right?

[nguerrera]

There's a tradeoff between more consistency with TargetFramework/TargetFrameworks + more terse project files and leveraging existing alternative patterns.

[kzu]

Yeah, it's the same concept. The capability denotes you can rely on the
ProjectConfiguration being there.

I'm helping out with a mostly native solution/nuget where the concept of
TargetFramework/s doesn't even exist, but they do have TargetPlatform/s
instead, with similar needs (i.e. cross targeting), and I was reminded of
the usefulness of that particular usage of MSBuild for introspection. It
basically allows me to implement the cross targeting by building all
configured platforms in the same way as TargetFramework/s

/kzu from mobile

[davkean]

Where are we leaning on this? Does this thread have all the context?

[kzu]

I think it does. Basically, follow on VC++ footsteps and provide a coherent
way to expose project configurations, rather than relying on conventional
Condition attributes.

[nguerrera]

@davkean This thread has all the context. The proposal is based on the consensus of a design discussion that @srivatsn and I had. I was not previously aware of the VC mechanism that @kzu pointed out. I still feel that is rather verbose vs, the proposal and still lean towards consistency with TargeFramework dimension on the other configuration dimensions. What are your thoughts?

[davkean]

Yeah had similar thoughts myself - still need to figure out a defaults story, and then figure out what we need to do on the VS side to make this all work.

[kzu]

With the XML attributes support, the syntax becomes quite a bit less
verbose though. Basically just one XML element per project configuration,
by default, no?