Skip to content

Conversation

@cdmihai
Copy link
Contributor

@cdmihai cdmihai commented Oct 31, 2019

Fixes #4677
Fixes #1054

This turned out to be more complicated than it should be in order to maintain backwards compatibility with legacy behaviour (described in #4677). For example, quickbuild depends on this bug and fixing it will take some time and it's probably low priority, so the ability to pin the bad behaviour and fix later is sadly okay here.

Feedback needed on:

  • the toggling property name and value. Right now it's $(MSBuildCopyContentTransitively ) where true means transitive, false means 1-level copying, nothing means legacy (which should be the same as false). Would you rather I named the values to transitive, 1-level, legacy and set it to legacy by default?
  • any ideas on automated testing, since the msbuild repo doesn't do any sdk integration testing. Since VS cares the most for what happens during BuildProjectReferences=false, seems like VS should test for this. Quickbuild will also test for this if it turns /isolate by default in its builds. Or I could add it to the Microsoft.Net.Sdk tests, if it wants to care about BuildProjectReferences=false

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Behavioral inconsistency with BuildProjectReferences=false IncrementalClean deletes transitively-acquired content in Visual Studio

3 participants