Changing the TargetFrameworks list for a loaded project does not always has an effect

[rainersigwald]

From @jeromelaban on April 5, 2018 17:3

In VS2017 15.7 Pre2, Win10 FCU:

• Create a Project A, with <TargetFrameworks>netstandard2.0;net46</TargetFrameworks>
• Create a Project B, with <TargetFrameworks>netstandard2.0;net46</TargetFrameworks>
• Make Project B reference project A
• Build once
• In the same VS instance, using the Edit csproj context menu
• Edit Project A, set <TargetFrameworks>netstandard2.0</TargetFrameworks>
• Save
• Edit Project B, set <TargetFrameworks>netstandard2.0</TargetFrameworks>
• Save
• Rebuild the solution

Sometimes, B won't compile because of a A does not target net46, a target that has just been removed.

Using these repro steps, you may also find that the Edit csproj context menu does not always open the file.

Copied from original issue: Microsoft/msbuild#3169

[jeromelaban]

Additionally, it seems to break the up-to-date checks which still checks for cached files from the removed target frameworks.

[Pilchie]

Similar to https://github.com/dotnet/project-system/issues/2657? Is this just fallout of the fact that the project system doesn't handle configurations changing right now?

[davkean]

Triage: Due to CPS limitations, we don't unload configurations - we should either dupe this against that work for some of the performance work we're doing, or we should specifically force the user to reload the project when we reduce the set of configurations.