Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'RuntimeType.TypeHandle' throws 'NotSupportedException' on NativeAOT after publishing with 0 ILC warnings #109496

Closed
Sergio0694 opened this issue Nov 4, 2024 · 2 comments · Fixed by #109875
Labels
area-NativeAOT-coreclr in-pr There is an active PR which will close this issue when it is merged partner-impact This issue impacts a partner who needs to be kept updated

Comments

@Sergio0694
Copy link
Contributor

Sergio0694 commented Nov 4, 2024

Description

Noticed a runtime crash in some IDIC scenarios while porting the Microsoft Store to Native AOT (.NET 9). This happens after publishing with 0 trim/AOT warnings from ILC (as well as the analyzers), so I'm inclined to think it's some issue in ILC not correctly tracking things during trimming.

Reproduction Steps

I don't really have a minimal repro, as this also requires all the preview UWP on .NET 9 tooling (this repros with some internal UWP XAML interface, so I don't have an equivalent for WinUI 3). However I can easily share repro steps if you're willing to clone the Store (eg. like we did in #109272 and related issues). I can also share crash dumps or anything else that can help.

Expected behavior

Code should work correctly on Native AOT.

Actual behavior

0x80049d08c0 [Type: S_P_CoreLib_System_NotSupportedException * (derived from S_P_CoreLib_System_Exception *)]

[+0x008] _message : 0x80049d0c48 : "'ABI.Windows.UI.Xaml.IFrameworkElementProtected7' is missing native code or metadata. This can happen for code that is not compatible with trimming or AOT. Inspect and fix trimming and AOT related warnings that were generated when the app was published. For more information see https://aka.ms/nativeaot-compatibility" [Type: String &]

Image

Regression?

No.

Known Workarounds

This seems to do the trick:

[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(ABI.Windows.UI.Xaml.IFrameworkElementProtected7))]

Configuration

  • VS 17.12 P5
  • .NET 9 RC2
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Nov 4, 2024
Copy link
Contributor

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

@Sergio0694 Sergio0694 added the partner-impact This issue impacts a partner who needs to be kept updated label Nov 4, 2024
@MichalStrehovsky
Copy link
Member

Has been broken since .NET 7.

We optimize away type handles when possible because one cannot do much with them without hitting actual trim-unsafe code. This case however can run into needing the type handle for trim safe code.

Repro:

using System.Reflection;
using System.Runtime.InteropServices;

object o = new CastableThing();
((IMyInterface)o).Method();

class CastableThing : IDynamicInterfaceCastable
{
    RuntimeTypeHandle IDynamicInterfaceCastable.GetInterfaceImplementation(RuntimeTypeHandle interfaceType)
    {
        return Type.GetTypeFromHandle(interfaceType).GetCustomAttribute<TypeAttribute>().TheType.TypeHandle;
    }

    bool IDynamicInterfaceCastable.IsInterfaceImplemented(RuntimeTypeHandle interfaceType, bool throwIfNotImplemented)
    {
        return Type.GetTypeFromHandle(interfaceType).IsDefined(typeof(TypeAttribute));
    }
}

[Type(typeof(IMyInterfaceImpl))]
interface IMyInterface
{
    void Method();
}

[DynamicInterfaceCastableImplementation]
interface IMyInterfaceImpl : IMyInterface
{
    void IMyInterface.Method() => Console.WriteLine("Hello");
}

class TypeAttribute : Attribute
{
    public Type TheType { get; }

    public TypeAttribute(Type t) => TheType = t;
}

MichalStrehovsky added a commit to MichalStrehovsky/runtime that referenced this issue Nov 15, 2024
Fixes dotnet#109496.

We try to optimize away type handles (MethodTables) of types that are only needed due to metadata. Trying to grab type handle of such type throws. This fixes it by unconditionally generating type handles of IDynamicInterfaceCastableImplementation.
@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Nov 15, 2024
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label Nov 16, 2024
github-actions bot pushed a commit that referenced this issue Nov 18, 2024
Fixes #109496.

We try to optimize away type handles (MethodTables) of types that are only needed due to metadata. Trying to grab type handle of such type throws. This fixes it by unconditionally generating type handles of IDynamicInterfaceCastableImplementation.
mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this issue Dec 10, 2024
…dotnet#109875)

Fixes dotnet#109496.

We try to optimize away type handles (MethodTables) of types that are only needed due to metadata. Trying to grab type handle of such type throws. This fixes it by unconditionally generating type handles of IDynamicInterfaceCastableImplementation.
@github-actions github-actions bot locked and limited conversation to collaborators Dec 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-NativeAOT-coreclr in-pr There is an active PR which will close this issue when it is merged partner-impact This issue impacts a partner who needs to be kept updated
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants