NativeAOT support for TypeIdentifier

[kant2002]

I trying to implemet WebView2 ComWrappers and they are working fine, except issue cause by this breakign change

https://www.fuget.org/packages/Microsoft.Web.WebView2/1.0.1462.37/lib/netcoreapp3.0/diff/1.0.1418.22/

I manage to produce workaround which works in CoreCLR without trimming.
I have two types withing single assembly which has same GuidAttribute and marked with TypeIdentifierAttribute. I implement both types in the class, so depending on which version of WebView2 nuget package I'm using, application use one interface or another.

If I use NativeAOT or use R2R with following settings.

<PublishReadyToRun>true</PublishReadyToRun>
<PublishTrimmed>true</PublishTrimmed>
<BuiltInComInteropSupport>true</BuiltInComInteropSupport>

then "something" is broken, for NativeAOT and R2R it's different kind of issues. Would be good if both variants supports TypeIdentifier (I assume that's problem with it.)

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I trying to implemet WebView2 ComWrappers and they are working fine, except issue cause by this breakign change

https://www.fuget.org/packages/Microsoft.Web.WebView2/1.0.1462.37/lib/netcoreapp3.0/diff/1.0.1418.22/

I manage to produce workaround which works in CoreCLR without trimming.
I have two types withing single assembly which has same GuidAttribute and marked with TypeIdentifierAttribute. I implement both types in the class, so depending on which version of WebView2 nuget package I'm using, application use one interface or another.

If I use NativeAOT or use R2R with following settings.

<PublishReadyToRun>true</PublishReadyToRun>
<PublishTrimmed>true</PublishTrimmed>
<BuiltInComInteropSupport>true</BuiltInComInteropSupport>

then "something" is broken, for NativeAOT and R2R it's different kind of issues. Would be good if both variants supports TypeIdentifier (I assume that's problem with it.)

Author:	kant2002
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[jkotas]

<PublishTrimmed>true</PublishTrimmed>
<BuiltInComInteropSupport>true</BuiltInComInteropSupport>

BuiltInComInteropSupport is not compatible with PublishTrimmed. Do you see the problem when BuiltInComInteropSupport is disabled?

[kant2002]

Without BuildIncomIteropSupport it fails with pretty typical

Could not load type 'System.StubHelpers.InterfaceMarshaler' from assembly 'System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.CreateCoreWebView2EnvironmentWithOptions(String , String , ICoreWebView2EnvironmentOptions, ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler)

If I add

<linker>
  <assembly fullname="System.Private.CoreLib">
    <type fullname="System.StubHelpers.InterfaceMarshaler" />
  </assembly>
</linker>

and <TrimmerRootDescriptor Include="ILLink.Descriptors.xml" /> App run, but WebView throw Exception thrown: 'System.MissingMethodException' in Microsoft.Web.WebView2.Core.dll which I was not able to intercept in mannaged debugger.
in Native debugger I was able to see that method name looks like this.

instance void [Microsoft.Web.WebView2.Core] Microsoft.Web.WebView2.Core.Raw.ICoreWebView2PrivatePartial::AddHostObjectHelper(class Microsoft.Web.WebView2.Core.Raw.ICoreWebView2PrivateHostObjectHelper)

I have exact same method defined here https://github.com/kant2002/WinFormsComInterop/blob/1af9bfadcae4a519ff609e58fa3cdc153adc7b33/WinFormsComInterop/WebView2/ICoreWebView2PrivatePartial.cs#L13-L17

I assume that TypeIdentifier should kick in and magic will happens, like it happens during regular CoreCLR execution.

Unmanaged stack trace

>	coreclr.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 75	C++
 	coreclr.dll!RealCOMPlusThrowHR(HRESULT hr, unsigned int resID, const wchar_t * wszArg1, const wchar_t * wszArg2, const wchar_t * wszArg3, const wchar_t * wszArg4, const wchar_t *) Line 11368	C++
 	coreclr.dll!VirtualCallStubManager::Resolver(MethodTable * pMT, DispatchToken token, Object * * protectedObj, unsigned __int64 * ppTarget, int throwOnConflict) Line 2195	C++
 	coreclr.dll!VirtualCallStubManager::ResolveWorker(StubCallSite * pCallSite, Object * * protectedObj, DispatchToken token, VirtualCallStubManager::StubKind stubKind) Line 1700	C++
 	coreclr.dll!ExternalMethodFixupWorker(TransitionBlock * pTransitionBlock, unsigned __int64 pIndirection, unsigned long sectionIndex, Module * pModule) Line 2587	C++
 	coreclr.dll!DelayLoad_MethodCall�()	Unknown
 	Microsoft.Web.WebView2.Core.dll!00007ffae6a961a7()	Unknown
 	Microsoft.Web.WebView2.Core.dll!00007ffae6a96569()	Unknown
 	Microsoft.Web.WebView2.Core.dll!00007ffae6a9b79f()	Unknown
 	WinFormsComInterop.dll!00007ffaf3c4f39e()	Unknown
 	EmbeddedBrowserWebView.dll!base::internal::Invoker<base::internal::BindState<`lambda at ../../edge_embedded_browser/client/win/current/embedded_browser_webview_environment.cc:871:11',Microsoft::WRL::ComPtr<ICoreWebView2CreateCoreWebView2ControllerCompletedHandler>>,void (long, embedded_browser_webview_current::Controller *)>::RunOnce()	Unknown

[jkoritzinsky]

The TypeIdentifier support is type equivalence, which is item number 3 on the list of limitations in NativeAOT that aren't planned to be addressed: #69919

[kant2002]

Cannot insist on that too much because my problem from WebView2 being aggressive in renaming, but items number 4 and 5 was also not planned, but we have something else instead. So maybe that's doable. I really don't know.

Also what about R2R? I think R2R is almost like regular CoreCLR.

[jkoritzinsky]

I think the general philosophy of R2R is that it should be a transparent optimization (aka behavior should not differ other than performance). If this is causing R2R-generated code to throw an exception that regular non-R2R code doesn't throw for a supported scenario, then I think that's a bug we should fix.

If you turn off PublishTrimmed but leave PublishReadyToRun on, do you see a difference in the behavior between R2R and non-R2R code?

[MichalStrehovsky]

I think for r2r this is tracked in #67855. For NativeAOT this looks by design.

[kant2002]

Just <PublishReadyToRun>true</PublishReadyToRun> working, so probably trimming trim something away, so at max, that's reporting issue.

Unrelated, I hit issue that if I remove PublishTrimmed from project, subsequent dotnet publish produce broken combination of bits. Should I report this?

For NativeAOT, is there chance that this is something that is relatively easy to have?

[MichalStrehovsky]

Just <PublishReadyToRun>true</PublishReadyToRun> working, so probably trimming trim something away, so at max, that's reporting issue.

<BuiltInComInteropSupport>true</BuiltInComInteropSupport> should really have been named <IPromiseNotToOpenIssuesInTheRuntimeRepo>true</IPromiseNotToOpenIssuesInTheRuntimeRepo>. Built-in COM and trimming don't work together.

For NativeAOT, is there chance that this is something that is relatively easy to have?

This allows stuff like the following:

(new Bar()).Blah(default);

[TypeIdentifier("foo", "bar")]
struct Fun { }
[TypeIdentifier("foo", "bar")]
struct Times { }

class Foo
{
    public virtual void Blah(Fun f) { }
}

class Bar : Foo
{
    public override void Blah(Times t) { }
}

The AOT compiler relies on referential identity between types for comparisons. Type equivalence adds a ton of confusing things into the compiler and might even leak out into runtime. There would need to be an extremely compelling reason to add it.

[kant2002]

I have only one case with WebView2 where I need this to account for their breaking change, so that's not important probably. If this happens in the future I always can release new package. But would it make sense to keep issue open, so it can collect cases specifically on TypeIdenfier suppor, if such issues arise? if not, you can close, I have my answers mostly.

[agocke]

We're not likely to do anything here.