Make HasRuntimeOutput change compatible with existing test sdk versions #1243
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nguerrera
force-pushed
the
runtime-output-compat
branch
from
22e70b5 to
00948d5
Compare
|
@MattGertz for approval |
dsplaisted
approved these changes
May 24, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#1178 caused projects using existing test SDK to break. Caught by dotnet test coverage in CLI repo.
The problem is that the test SDK changes the OutputType in targets after we've already set some variables based on it.
This is blocking the ingestion of a new dotnet/SDK into dotnet/CLI
Customer scenario
Using a unit test project that references a version of the test sdk that has not yet implemented microsoft/vstest#792 (which at this time is all versions of the test sdk because the feature isn't implemented yet.
Bugs this fixes:
None filed because it was found during ingestion of dotnet/sdk to dotnet/cli so nobody was impacted by it yet.
Workarounds, if any
None.
Risk
Low.
Performance impact
Low.
Is this a regression from a previous update?
It is a regression in this repo, but it never saw the light of day because we caught it in CLI repo on its way to the outside world.
Root cause analysis:
Lack of test coverage in sdk repo, relying on CLI tests to catch it. I've added a test in this repo to prevent the long turn around on finding another similar regression.
How was the bug found?
Automated testing