[release/8.0-staging] Add runtime config parameter to force ijwhost to load assemblies in an isolated context #105436
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
…n isolated context (dotnet#105337) * Add support for isolated load context in LoadInMemoryAssemblyInContext by passing -1 as loadContext * Have ijwhost check a runtime config parameter to determine if it should run in an isolated load context * Added test for ijwhost isolated load context runtime config option
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
AaronRobinsonMSFT
approved these changes
Jul 24, 2024
jeffschwMSFT
approved these changes
Jul 25, 2024
rbhanda
added
Servicing-approved
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.
Backport of #105337 to release/8.0-staging
cc @mikeoliphant @AaronRobinsonMSFT
Customer Impact
Issue: #104480
When trying to load a second copy of a C++/CLI assembly that has already been loaded from a different location, the runtime ends up in an infinite loop calling into the
ijwhoststub for starting the runtime/loading the managed assembly. There is no workaround.Regression
We made a change to make C++/CLI assemblies always load in the default ALC - this was based on common user feedback / pain points and made the behaviour better match .NET Framework (that migration being the major use case). However, this ends up breaking the reported scenario where multiple copies of a C++/CLI assembly (same assembly name in metadata) are loaded from different locations.
Testing
Customer validated (and implemented). Automated tests added.
Risk
Low. This adds a configuration option the change the load behaviour. It does not change the default behaviour.