Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate configuration behavior when the values (Configurations/Platforms/TargetFrameworks) are conditioned or duplicated. #1829

Open
RaulPerez1 opened this issue Mar 22, 2017 · 0 comments

Comments

Projects
None yet
3 participants
@RaulPerez1
Copy link
Contributor

commented Mar 22, 2017

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:

  1. 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).

  2. 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.

  3. 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.

@srivatsn srivatsn added this to the 16.0 milestone Mar 31, 2017

@srivatsn srivatsn added the Bug label Mar 31, 2017

@jjmew jjmew modified the milestones: 16.0, 16.X Feb 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.