Improvements to the patching of dependencies for the dotnet.exe tests, don't overwrite higher versions of assemblies #5054
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.
Bug
Fixes: https://github.com/NuGet/Client.Engineering/issues/2157
Regression? Last working version:
Description
When the new version of the .NET SDK shipped yesterday, it broke some of our tests as our infrastructure started downloading 7.0.200 instead of 7.0.1xx SDK it used.
The correct behavior is to test against newer versions, so we need fix our tests to work with that.
This is a multi-fix PR;
Stop calling dotnet.exe with
--output
on a solution file. This was disallowed. See Breaking change inside v7.0.200 - MSBuild Preview version used !? dotnet/sdk#30624,There was a fix in Add error when specifying --output option for a solution dotnet/sdk#29065 for Error, warn, or fix behavior when specifying output path when building a solution dotnet/sdk#15607 which errors/warns for specifying output path for solution.
In the past for our dotnet.exe integration tests, prior to 84d99ce, we used to patch only the NuGet assemblies. If we needed an extra assembly we'd hardcode it. In the linked change, we started copying the new dependencies automatically. Unfortunately this can cause problems sometimes because the version we'd copy would be older than the version in the .NET SDK and cause problems.
Instead of having a platform specific implementation, for the protecteddata dll, in newer runtimes, ashared implementation of the protecteddata.dll will be called. Unfortunately our patching would overwrite that shared implementation with an older version, which is NS2.0, and not appropriate.
PR Checklist
PR has a meaningful title
PR has a linked issue.
Described changes
Tests
Documentation