Currently the expectation is that the values are only once in the project and unconditioned (since they are usually what you use as a condition). Now consider the following cases:
Values defined in a conditioned property group
<PropertyGroup Condition="'$(OS)' == '1''">
<Configurations>Debug_OS1</Configurations>
</PropertyGroup>
<PropertyGroup Condition="'$(OS)' == '2''">
<Configurations>Debug_OS1;Debug_OS2</Configurations>
</PropertyGroup>
Values with a specific condition
<PropertyGroup>
<TargetFrameworks>TFM1</TargetFrameworks>
<TargetFrameworks Condition="'$(OS)' == '1''">$(TargetFrameworks);TFM1</TargetFrameworks>
</PropertyGroup>
Values defined more than once
<PropertyGroup>
<Platforms>x86</Platforms>
<Platforms>$(Platforms);x64</Platforms>
</PropertyGroup>
When reading the values to populate the dimensions they are populated based on the evaluated values so all these cases are covered. When writing them however it's using the construction model (since values coming from targets can't be written on top of) and picking the first value from the construction model which ignores conditions and duplicated values.
We could change the saving part use the evaluation model if the property is coming from the project and not an import. There are some design issues to take into account with this approach:
-
Things like the configuration manager will only work on the current conditioned value (e.g. with my example above if I delete Debug_OS1 it will only be removed from the current evaluated value).
-
Similar to the example above renaming something will rename all the conditions in the project that are consuming that configuration. Since the value on the other value will not be renamed when falling into that condition things will not be conditioned properly.
-
Removing something like a platform would remove all of the platform items for the projects regardless of the condition. When going into a separate conditioned platform where the removed platform is still defined there will not be anything conditioned to it.
All of this behavior may or may not be desirable as this is uncharted territory.
Currently the expectation is that the values are only once in the project and unconditioned (since they are usually what you use as a condition). Now consider the following cases:
Values defined in a conditioned property group
Values with a specific condition
Values defined more than once
When reading the values to populate the dimensions they are populated based on the evaluated values so all these cases are covered. When writing them however it's using the construction model (since values coming from targets can't be written on top of) and picking the first value from the construction model which ignores conditions and duplicated values.
We could change the saving part use the evaluation model if the property is coming from the project and not an import. There are some design issues to take into account with this approach:
Things like the configuration manager will only work on the current conditioned value (e.g. with my example above if I delete Debug_OS1 it will only be removed from the current evaluated value).
Similar to the example above renaming something will rename all the conditions in the project that are consuming that configuration. Since the value on the other value will not be renamed when falling into that condition things will not be conditioned properly.
Removing something like a platform would remove all of the platform items for the projects regardless of the condition. When going into a separate conditioned platform where the removed platform is still defined there will not be anything conditioned to it.
All of this behavior may or may not be desirable as this is uncharted territory.