You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fail predictably and with better error message for WinRT #182
This is for situation when an assembly being compiled to native code refers to a WinMD. NativeAot should be able to co-exist with WinRT runtime in the process - it just can't talk to it through the WinRT ABI directly.
Built-in support for WinRT was yanked from CoreCLR too, so this issue tracks simulating whatever error mode CoreCLR has for this.
(CsWinRT solves the problem for .NET 5 in general after support in the runtime has been yanked. NativeAOT currently lacks a component that CsWinRT depends on, but that will be the WinRT support story for NativeAOT eventually too.)
NativeAOT will fast fail the process seemingly if it something that is unrealated to it throwing a com exception (or for that matter any hardware exception) even if its outside of its mapped address space which is very frustrating when (in my situation) you have no control over the code that throws that in question (libcef loading winapi loading combase which causes NativeAOT to go to RhpThrowHwEx and fastfail the process)
Activity
[-]Fail predictably for WinRT[/-][+]Fail predictably and with better error message for WinRT[/+]emily33901 commentedon Nov 3, 2020
Think I might have run into this one - is it just in any case of WinRT being used in the process where nativeaot is being run?
MichalStrehovsky commentedon Nov 3, 2020
This is for situation when an assembly being compiled to native code refers to a WinMD. NativeAot should be able to co-exist with WinRT runtime in the process - it just can't talk to it through the WinRT ABI directly.
Built-in support for WinRT was yanked from CoreCLR too, so this issue tracks simulating whatever error mode CoreCLR has for this.
(CsWinRT solves the problem for .NET 5 in general after support in the runtime has been yanked. NativeAOT currently lacks a component that CsWinRT depends on, but that will be the WinRT support story for NativeAOT eventually too.)
emily33901 commentedon Nov 4, 2020
NativeAOT will fast fail the process seemingly if it something that is unrealated to it throwing a com exception (or for that matter any hardware exception) even if its outside of its mapped address space which is very frustrating when (in my situation) you have no control over the code that throws that in question (libcef loading winapi loading combase which causes NativeAOT to go to RhpThrowHwEx and fastfail the process)
jkotas commentedon Nov 4, 2020
@emily33901 Could you please open a new issue on this, include the stacktrace where you see
RhpThrowHwExgetting called?emily33901 commentedon Nov 4, 2020
Yeah will do
Reject WinRT metadata types in compiler type validation (#133397)