This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Always compare TPA versions (#4423) #4521
Merged
Conversation
This file contains 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
steveharter
added
the
* NO MERGE *
natemcmaster
added
the
Servicing-consider
natemcmaster
approved these changes
Aug 31, 2018
|
Waiting on email. |
|
Approved for 2.1.5. Test plan required to mitigate risk. |
|
Test plan added at https://github.com/dotnet/core-setup/issues/4541. In general, there are two areas of concern:
The test plan covers 1 and adds additional tests in second commit in this PR that verify TPA version checks in additional scenarios, ensuring behavior is as exepected between app and framework(s) regarding who will win by TPA version, ties and ensure roll-forward behavior (including patch) does not affect that. |
steveharter
removed
the
* NO MERGE *
|
Feedback from separate mail thread indicates this is OK to merge |
dsplaisted
added a commit
to dotnet/sdk
that referenced
this pull request
Oct 17, 2018
This test was previously incorrect. It was using the wrong property name to try to disable version information from being written to the deps file. This meant that version information was being written to the deps file. Furthermore, the test expectation was backwards from the test name: the test was erroneously expecting the DLL to be loaded from the app's publish directory. The broken version of the test started failing once we got a stage 0 that included this fix: dotnet/core-setup#4521. That PR changed the behavior when the versions of the file in the published app and the runtime matched. In that case, the runtime will now prefer the runtime copy instead of the app's copy.
nguerrera
pushed a commit
to nguerrera/sdk
that referenced
this pull request
Oct 17, 2018
This test was previously incorrect. It was using the wrong property name to try to disable version information from being written to the deps file. This meant that version information was being written to the deps file. Furthermore, the test expectation was backwards from the test name: the test was erroneously expecting the DLL to be loaded from the app's publish directory. The broken version of the test started failing once we got a stage 0 that included this fix: dotnet/core-setup#4521. That PR changed the behavior when the versions of the file in the published app and the runtime matched. In that case, the runtime will now prefer the runtime copy instead of the app's copy.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes https://github.com/dotnet/core-setup/issues/4512
Original issue: https://github.com/dotnet/core-setup/issues/4376
Description
Compare assemblyVersion\fileVersion for patch roll-forward cases to support better serviceability and to prevent run-time FileLoadException from occurring due to assembly-to-assembly versions being too low. Previously the runtime only compared versions for minor- and major roll-forward scenarios. The reason was because it allowed for the app to have complete control over any duplicated assemblies that exist in the app bin location, to support build-from-source and other explicit scenarios.
Customer Impact
If an application wishes to always load their "app local" copies of framework assemblies (for example, if they have a build-from-source scenario with new features or bug fixes) then they should prevent Minor\Major roll-forward and patch roll-forward from occurring by modifying their runtimeconfig.json to add applyPatches:false and rollForwardOnNoCandidateFx" : 0 like so:
Regression?
No
Risk
Some, although should be rare. As noted in the description, this helps with serviceability when we release new versions of framework assemblies in a patch release. However, if the customer always expects the older "app local" version to be loaded then they will need to either: