From @pranavkm:
Here’s a summary of the issue:
• Application references LibraryA
• LibraryB references LibraryA
• We create a ProjectLoadContext and use it to load LibraryB
Using Microsoft.NETCore.App 1.0.0, types from LibraryA in the default load context and the created load context are unified. With 1.1.0-preview1-001090-00, this no longer seems to be true.
And also the following analysis:
.NET Core 1.0.0 had a bug where for the scenario below we would endup loading LibraryA from DefaultLoadContext directly, without first allowing the custom load context (ProjectLoadContext in the example below) to perform the resolution of the requested load (of LibraryA). Only if the custom load context does not resolve the assembly should we fallback to DefaultLoadContext to look for the assembly.
From @pranavkm:
The LoadContext we use is from the CLI - https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.ProjectModel.Loader/ProjectLoadContext.cs#L61-L70 and it doesn't have this behavior. I'll figure out if we can get them to take a fix for this or if we can workaround by wrapping their load context in our tool's callsite.
More details are in https://github.com/dotnet/coreclr/issues/7493.
CC @leecow @Eilon @livarcocc @piotrpMSFT @eerhardt
From @pranavkm:
Here’s a summary of the issue:
• Application references LibraryA
• LibraryB references LibraryA
• We create a ProjectLoadContext and use it to load LibraryB
Using Microsoft.NETCore.App 1.0.0, types from LibraryA in the default load context and the created load context are unified. With 1.1.0-preview1-001090-00, this no longer seems to be true.
And also the following analysis:
.NET Core 1.0.0 had a bug where for the scenario below we would endup loading LibraryA from DefaultLoadContext directly, without first allowing the custom load context (ProjectLoadContext in the example below) to perform the resolution of the requested load (of LibraryA). Only if the custom load context does not resolve the assembly should we fallback to DefaultLoadContext to look for the assembly.
From @pranavkm:
The LoadContext we use is from the CLI - https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.ProjectModel.Loader/ProjectLoadContext.cs#L61-L70 and it doesn't have this behavior. I'll figure out if we can get them to take a fix for this or if we can workaround by wrapping their load context in our tool's callsite.
More details are in https://github.com/dotnet/coreclr/issues/7493.
CC @leecow @Eilon @livarcocc @piotrpMSFT @eerhardt