-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Conversation
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
@@ -6925,20 +6927,27 @@ HRESULT RuntimeInvokeHostAssemblyResolver(INT_PTR pManagedAssemblyLoadContextToB | |||
pAssemblyBindingContext = pLoadedPEAssembly->GetHostAssembly(); | |||
} | |||
|
|||
#ifdef FEATURE_COMINTEROP | |||
if (AreSameBinderInstance(pAssemblyBindingContext, GetAppDomain()->GetWinRtBinder())) | |||
if (fResolvedAssembly) |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
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 |
This reverts commit 597e5fa.
This reverts commit 74f26ab.
* 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
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