Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Remove premature throw #24450

Merged
merged 4 commits into from
May 9, 2019
Merged

Remove premature throw #24450

merged 4 commits into from
May 9, 2019

Conversation

sdmaclea
Copy link

@sdmaclea sdmaclea commented May 7, 2019

ResolveUsingEvent is no longer the last resort for Assembly resolution
and should not be throwing simply because the Assembly.Resolve event did
not find the Assembly

@sdmaclea sdmaclea added tenet-performance Performance related issue area-AssemblyLoader labels May 7, 2019
@sdmaclea sdmaclea added this to the 3.0 milestone May 7, 2019
@sdmaclea sdmaclea self-assigned this May 7, 2019
ResolveUsingEvent is no longer the last resort for Assembly resolution
and should not be throwing simply because the Assembly.Resolve event did
not find the Assembly
@sdmaclea sdmaclea changed the title WIP Remove premature throw Remove premature throw May 8, 2019
@@ -6925,20 +6927,27 @@ HRESULT RuntimeInvokeHostAssemblyResolver(INT_PTR pManagedAssemblyLoadContextToB
pAssemblyBindingContext = pLoadedPEAssembly->GetHostAssembly();
}

#ifdef FEATURE_COMINTEROP
if (AreSameBinderInstance(pAssemblyBindingContext, GetAppDomain()->GetWinRtBinder()))
if (fResolvedAssembly)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code was written assuming line 6884 above threw...

Mostly whitepace below

}
else
{
hr = COR_E_FILENOTFOUND;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Return COR_E_FILENOTFOUND instead of throwing FILENOTFOUND

@jkotas
Copy link
Member

jkotas commented May 9, 2019

Do we need a test for this? How did we find the issue that this is fixing?

@sdmaclea
Copy link
Author

sdmaclea commented May 9, 2019

Do we need a test for this? How did we find the issue that this is fixing?

Ben Watson reported this. He was debugging in Visual Studio plugin isolation. He enabled breaking on first chance exceptions and he was seeing these exception despite successfully loading with the AppDomain.AssemblyResolve event.

Not sure if I can catch it in a test with a AppDomain.FirstChance exception handler. I'll give it a try

@sdmaclea sdmaclea merged commit 597e5fa into dotnet:master May 9, 2019
@sdmaclea sdmaclea deleted the ResolveUsing branch May 9, 2019 02:33
sdmaclea added a commit to sdmaclea/coreclr that referenced this pull request May 10, 2019
sdmaclea added a commit to sdmaclea/coreclr that referenced this pull request May 10, 2019
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
* Remove premature throw

ResolveUsingEvent is no longer the last resort for Assembly resolution
and should not be throwing simply because the Assembly.Resolve event did
not find the Assembly

* Delay throw FileNotFound until after AppDomain.AssemblyResolve


Commit migrated from dotnet/coreclr@597e5fa
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
2 participants