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

[BUG] ExecutionEngineException when deserializing generic [DataContract] on iOS (Realease Build, only through app store) #78889

Closed
AbstractionsAs opened this issue Nov 27, 2022 · 39 comments
Assignees
Milestone

Comments

@AbstractionsAs
Copy link

Description

Exception thrown when deserializing datacontract on iOS.
The problem only occurs when the app has been deployed through AppStore/TestFlight.

System.ExecutionEngineException: Attempting to JIT compile method '(wrapper delegate-invoke) void <Module>:invoke_callvirt_void_Element_string (AnleggsSentralen.Checklist.Element,string)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information.

   at System.Runtime.Serialization.FastInvokerBuilder.<>c__DisplayClass12_1`2[[AnleggsSentralen.Checklist.Element, AnleggsSentralen.Checklist, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null],[System.String, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].<CreateSetterInternal>b__1(Object& , Object )
   at System.Runtime.Serialization.ReflectionReader.ReflectionSetMemberValue(Object& , Object , DataMember )
   at System.Runtime.Serialization.ReflectionReader.ReflectionReadMember(XmlReaderDelegator , XmlObjectSerializerReadContext , ClassDataContract , Object& , Int32 , DataMember[] )
   at System.Runtime.Serialization.ReflectionXmlReader.ReflectionReadMembers(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] , ClassDataContract , Object& )
   at System.Runtime.Serialization.ReflectionReader.ReflectionReadClass(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] , ClassDataContract )
   at System.Runtime.Serialization.ReflectionXmlClassReader.ReflectionReadClass(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )
   at System.Runtime.Serialization.DataContracts.ClassDataContract.ReadXmlValue(XmlReaderDelegator , XmlObjectSerializerReadContext )
   at System.Runtime.Serialization.XmlObjectSerializerReadContext.ReadDataContractValue(DataContract , XmlReaderDelegator )
   at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator reader, String name, String ns, Type declaredType, DataContract& dataContract)
   at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator xmlReader, Type declaredType, DataContract dataContract, String name, String ns)
   at System.Runtime.Serialization.DataContractSerializer.InternalReadObject(XmlReaderDelegator , Boolean , DataContractResolver )
   at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator , Boolean , DataContractResolver )
   at System.Runtime.Serialization.XmlObjectSerializer.ReadObject(XmlDictionaryReader )
   at System.Runtime.Serialization.XmlObjectSerializer.ReadObject(Stream )
   at AnleggsSentralen.Checklist.Checklist.Load(Stream stream)
   at AnleggsSentralen.Checklist.Checklist.LoadAsync(Stream stream)
   at AnleggsSentralen.Client.Services.ChecklistService.GetChecklistTemplateAsync(Int32 id)
   at AnleggsSentralen.App.Services.DataLake.<GetDraftAsync>d__27`1[[AnleggsSentralen.Checklist.Checklist, AnleggsSentralen.Checklist, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext()
   at AnleggsSentralen.App.ViewModels.ChecklistViewModel.LoadChecklistFromTemplateAsync()
   at Herreruud.Framework.Mvvm.AsyncHelper.TraceExceptions(Func`1 factory, String method, String path)

Reproduction Steps

Deserialize generic datacontract on iOS in release build through AppStore/TestFlight.
I am unable to reproduce locally.

Expected behavior

The datacontract should deserialize

Actual behavior

ExecutionEngine is thrown

Regression?

No response

Known Workarounds

No response

Configuration

  • net7.0-ios
  • ios
  • AppStore
  • Arm64

Other information

In the file "src/libraries/System.Private.DataContractSerialization/src/System/Runtime/Serialization/AccessorBuilder.cs", I can find the following code, that I suspect is the problem:

// If either of the arguments to MakeGenericMethod is a valuetype, this is going to cause JITting.
 // Only JIT if dynamic code is supported.
 if (RuntimeFeature.IsDynamicCodeSupported || (!declaringType.IsValueType && !propertyType.IsValueType))
    {
        #pragma warning disable IL3050 // AOT compiling should recognize that this call is gated by RuntimeFeature.IsDynamicCodeSupported.
       var createSetterGeneric = s_createSetterInternal.MakeGenericMethod(propInfo.DeclaringType!, propInfo.PropertyType).CreateDelegate<Func<PropertyInfo, Setter>>();
        #pragma warning restore IL3050 // Calling members annotated with 'RequiresDynamicCodeAttribute' may break functionality when AOT compiling.
            return createSetterGeneric(propInfo);
        }
        else
        {
            return (ref object obj, object? val) =>
            {
                propInfo.SetValue(obj, val);
            };
        }

Also, The method itself is annotated with:

[UnconditionalSuppressMessage("ReflectionAnalysis", "IL2060:MakeGenericMethod",
            Justification = "The call to MakeGenericMethod is safe due to the fact that FastInvokerBuilder.CreateSetterInternal<T, T1> is not annotated.")]
        public static Setter CreateSetter(MemberInfo memberInfo)
@ghost ghost added the untriaged New issue has not been triaged by the area owner label Nov 27, 2022
@AbstractionsAs AbstractionsAs changed the title ExecutionEngineException when deserializing generic [DataContract] on iOS (Realease Build, only through app store) [BUG] ExecutionEngineException when deserializing generic [DataContract] on iOS (Realease Build, only through app store) Nov 28, 2022
@marek-safar marek-safar added the os-ios Apple iOS label Nov 28, 2022
@ghost
Copy link

ghost commented Nov 28, 2022

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

Exception thrown when deserializing datacontract on iOS.
The problem only occurs when the app has been deployed through AppStore/TestFlight.

System.ExecutionEngineException: Attempting to JIT compile method '(wrapper delegate-invoke) void <Module>:invoke_callvirt_void_Element_string (AnleggsSentralen.Checklist.Element,string)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information.

   at System.Runtime.Serialization.FastInvokerBuilder.<>c__DisplayClass12_1`2[[AnleggsSentralen.Checklist.Element, AnleggsSentralen.Checklist, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null],[System.String, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].<CreateSetterInternal>b__1(Object& , Object )
   at System.Runtime.Serialization.ReflectionReader.ReflectionSetMemberValue(Object& , Object , DataMember )
   at System.Runtime.Serialization.ReflectionReader.ReflectionReadMember(XmlReaderDelegator , XmlObjectSerializerReadContext , ClassDataContract , Object& , Int32 , DataMember[] )
   at System.Runtime.Serialization.ReflectionXmlReader.ReflectionReadMembers(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] , ClassDataContract , Object& )
   at System.Runtime.Serialization.ReflectionReader.ReflectionReadClass(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] , ClassDataContract )
   at System.Runtime.Serialization.ReflectionXmlClassReader.ReflectionReadClass(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )
   at System.Runtime.Serialization.DataContracts.ClassDataContract.ReadXmlValue(XmlReaderDelegator , XmlObjectSerializerReadContext )
   at System.Runtime.Serialization.XmlObjectSerializerReadContext.ReadDataContractValue(DataContract , XmlReaderDelegator )
   at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator reader, String name, String ns, Type declaredType, DataContract& dataContract)
   at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator xmlReader, Type declaredType, DataContract dataContract, String name, String ns)
   at System.Runtime.Serialization.DataContractSerializer.InternalReadObject(XmlReaderDelegator , Boolean , DataContractResolver )
   at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator , Boolean , DataContractResolver )
   at System.Runtime.Serialization.XmlObjectSerializer.ReadObject(XmlDictionaryReader )
   at System.Runtime.Serialization.XmlObjectSerializer.ReadObject(Stream )
   at AnleggsSentralen.Checklist.Checklist.Load(Stream stream)
   at AnleggsSentralen.Checklist.Checklist.LoadAsync(Stream stream)
   at AnleggsSentralen.Client.Services.ChecklistService.GetChecklistTemplateAsync(Int32 id)
   at AnleggsSentralen.App.Services.DataLake.<GetDraftAsync>d__27`1[[AnleggsSentralen.Checklist.Checklist, AnleggsSentralen.Checklist, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext()
   at AnleggsSentralen.App.ViewModels.ChecklistViewModel.LoadChecklistFromTemplateAsync()
   at Herreruud.Framework.Mvvm.AsyncHelper.TraceExceptions(Func`1 factory, String method, String path)

Reproduction Steps

Deserialize generic datacontract on iOS in release build through AppStore/TestFlight.
I am unable to reproduce locally.

Expected behavior

The datacontract should deserialize

Actual behavior

ExecutionEngine is thrown

Regression?

No response

Known Workarounds

No response

Configuration

  • net7.0-ios
  • ios
  • AppStore
  • Arm64

Other information

In the file "src/libraries/System.Private.DataContractSerialization/src/System/Runtime/Serialization/AccessorBuilder.cs", I can find the following code, that I suspect is the problem:

// If either of the arguments to MakeGenericMethod is a valuetype, this is going to cause JITting.
 // Only JIT if dynamic code is supported.
 if (RuntimeFeature.IsDynamicCodeSupported || (!declaringType.IsValueType && !propertyType.IsValueType))
    {
        #pragma warning disable IL3050 // AOT compiling should recognize that this call is gated by RuntimeFeature.IsDynamicCodeSupported.
       var createSetterGeneric = s_createSetterInternal.MakeGenericMethod(propInfo.DeclaringType!, propInfo.PropertyType).CreateDelegate<Func<PropertyInfo, Setter>>();
        #pragma warning restore IL3050 // Calling members annotated with 'RequiresDynamicCodeAttribute' may break functionality when AOT compiling.
            return createSetterGeneric(propInfo);
        }
        else
        {
            return (ref object obj, object? val) =>
            {
                propInfo.SetValue(obj, val);
            };
        }

Also, The method itself is annotated with:

[UnconditionalSuppressMessage("ReflectionAnalysis", "IL2060:MakeGenericMethod",
            Justification = "The call to MakeGenericMethod is safe due to the fact that FastInvokerBuilder.CreateSetterInternal<T, T1> is not annotated.")]
        public static Setter CreateSetter(MemberInfo memberInfo)
Author: AbstractionsAs
Assignees: -
Labels:

area-Serialization, untriaged, os-ios

Milestone: -

@marek-safar marek-safar added area-Codegen-AOT-mono and removed area-Serialization untriaged New issue has not been triaged by the area owner labels Nov 28, 2022
@marek-safar marek-safar added this to the 8.0.0 milestone Nov 28, 2022
@marek-safar
Copy link
Contributor

/cc @SamMonoRT

@steveisok
Copy link
Member

@AbstractionsAs, if you add <UseInterpreter>true</UseInterpreter> to your project, this should work. As your description shows, the problem is that creating delegates on the fly is something that is not currently supported in Mono AOT.

@AbstractionsAs
Copy link
Author

AbstractionsAs commented Nov 28, 2022 via email

@AbstractionsAs
Copy link
Author

@steveisok THis is what I've tried in the .csproj. Any idea why this doesn't have any effect? This is a blocker for me..

<PropertyGroup Condition="$(TargetFramework.Contains('-ios')) and '$(Configuration)' == 'Release'">
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
    <ArchiveOnBuild>true</ArchiveOnBuild>
    <UseInterpereter>true</UseInterpereter>
    <AdditionalArgs>--interpreter</AdditionalArgs>
  </PropertyGroup>

@steveisok
Copy link
Member

I don't think you need AdditionalArgs.

@AbstractionsAs, you still get the same exception even with interpreter enabled?

@AbstractionsAs
Copy link
Author

AbstractionsAs commented Nov 29, 2022

@steveisok Yeah - same exception. It doesn't seem like <UseInterpereter>true</UseInterpereter> actually does anything. That's why I tried using AdditionalArgs as well. Everything works fine when testing locally, though.

It seems to me that the code in AccessorBuilder.cs makes some incorrect assumptions.
The if RuntimeFeature.IsDynamicCodeSupported || (!declaringType.IsValueType && !propertyType.IsValueType) returns true because the declaring type is a class, and the property type is string (not a value type). According to the comment, this should not cause JIT, but clearly it does. If the if statement above had returned false I imagine everything would have worked..

@LeVladIonescu
Copy link
Contributor

@AbstractionsAs Can you please provide a sample app which can reproduce the issue?

@AbstractionsAs
Copy link
Author

@LeVladIonescu Can I send you a zip with some of my code files? The app itself is quite large, and it uses a ton of packages from our private feeds - including the one containing the datacontracts.

Perhaps if I send you the datacontracts, and the code we use to deserialize? It only fails when pushed through the App Store (the page does not render, and the exception is sent to my logging server), but everything works like a charm when debugging locally.

@AbstractionsAs
Copy link
Author

@LeVladIonescu If not I'll attempt to create another, simpler, app with the problem, but I'll have to actually push it all the way though the app store to reproduce the problem

@LeVladIonescu
Copy link
Contributor

LeVladIonescu commented Dec 2, 2022

@AbstractionsAs Creating a simpler app would be easier for me to understand the problem. Let me know if you will do that, otherwise we will stick to those bigger source codes.
I will start looking into it next week.

@AbstractionsAs
Copy link
Author

AOT Serialization Bug.zip
@LeVladIonescu With this one I was able to reproduce the issue locally using a release build deployed without debugging to local device

@LeVladIonescu
Copy link
Contributor

@AbstractionsAs Thanks for it

@AbstractionsAs
Copy link
Author

@LeVladIonescu Is there any update or timeline on this? It's a big blocker for me...

@LeVladIonescu
Copy link
Contributor

@AbstractionsAs I had a lot of issues regarding my certificates, I've resolved them now. I still get an error for the release build right now, debug build works properly. Working on it right now..

@LeVladIonescu
Copy link
Contributor

LeVladIonescu commented Dec 19, 2022

@AbstractionsAs what IOS Distribution Channel have you used when publishing the archive you provided?
Ad hoc / App Store / Enterprise?

@AbstractionsAs
Copy link
Author

@LeVladIonescu Thanks. Distribution channel is "App Store", I think.

@LeVladIonescu
Copy link
Contributor

LeVladIonescu commented Dec 19, 2022

@AbstractionsAs just to confirm it, you've managed to reproduce the bug with this archive by deploying it on TestFlight, right?
With a release build I couldn't reproduce the issue locally.
Can you provide the following?

  • exact versions of .NET SDK and Xamarin/MAUI
  • your steps to build/deploy/run the app

@AbstractionsAs
Copy link
Author

@LeVladIonescu Yeah, with this build I've reproduced it both locally and on TestFlight. I believe it's the latest versions of everything, but I'll double check that shortly

@AbstractionsAs
Copy link
Author

@LeVladIonescu Here's everything, I think:

  1. Screenshots of reproduction with the build I uploaded, including details about the device

ios-screenshots

  1. I think this is all the relevant version information from my dev machine

Version 17.4.2
VisualStudio.17.Release/17.4.2+33122.133
Microsoft .NET Framework
Version 4.8.04084


C# Tools   4.4.0-6.22565.8+53091686b435746d62a5df56abfab0e71203d83a
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Mono Debugging for Visual Studio   17.4.19 (8c0a575)
Support for debugging Mono processes with Visual Studio.

VisualStudio.DeviceLog   1.0
Information about my package

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

VSPackage Extension   1.0
VSPackage Visual Studio Extension Detailed Info

Xamarin   17.4.0.301 (d17-4@96af3ae)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   17.4.0.138 (remotes/origin/d17-4@d36bba3cc9)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   17.4.2 (c457c97)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   13.1.0.1 (d17-4/13ba222)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: a96bde9
    Java.Interop: xamarin/java.interop/d17-4@fcc33ce2
    SQLite: xamarin/sqlite/3.39.3@23e1ae7
    Xamarin.Android Tools: xamarin/xamarin-android-tools/main@0be567a


Xamarin.iOS and Xamarin.Mac SDK   16.0.0.92 (3dd3dc52c)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
  1. MacOS Build host runs MacOs Ventura 13.0.1 and XCode 14.1

@AbstractionsAs
Copy link
Author

@LeVladIonescu I see that the above dump didn't include SDK version: 7.0.100

@LeVladIonescu
Copy link
Contributor

LeVladIonescu commented Jan 5, 2023

Hi @AbstractionsAs , I wasn't able to reproduce this so I suggest to have a conversation on Discord whenever you are available. (join Dotnet Evolution Channel on Discord - https://aka.ms/dotnet-discord)

My versions :
Operating System
Mac OS X 13.1.0

Visual Studio Enterprise 2022 for Mac
Version 17.4.2 (build 17)

SDK Version: 7.0.101

Xamarin.Profiler
Version: 1.8.0.19

Apple Developer Tools
Xcode 14.2 (21534)

Xamarin.iOS
Version: 16.1.1.27 (Visual Studio Enterprise)

@AbstractionsAs
Copy link
Author

@LeVladIonescu I've never used discord before, but I'll install it and connect after my next meeting. That ok?

@LeVladIonescu
Copy link
Contributor

@AbstractionsAs that's alright. Here is my username : LeVladIonescu13#0017

@AbstractionsAs
Copy link
Author

@LeVladIonescu Any progress on this?

@LeVladIonescu
Copy link
Contributor

@AbstractionsAs working on it..

@LeVladIonescu
Copy link
Contributor

LeVladIonescu commented Jan 19, 2023

@AbstractionsAs Can you please double check if <UseInterpreter>true</UseInterpreter> has no effect for your project?
Given your sample archive, when enabling this argument the exception was not thrown. Also make sure that you properly clean and remove /bin and /obj from your project prior to building it again.

@AbstractionsAs
Copy link
Author

@LeVladIonescu Sorry, I've been away. The setting has no effect (that I can tell) on my main project. I haven't tried it with the demo project.

I still think the following snippet reveals th eproblem, though:

if (RuntimeFeature.IsDynamicCodeSupported || (!declaringType.IsValueType && !propertyType.IsValueType))

The correct way of fixning it might be figuring out why the strings in question causes JIT - given that strings are not value types, but simply removing the second part of the if should probably fix it as well.

Also, why does this not occur for debug builds? I have a debug build in production in the AppStore right now (unfortunatly).

@MichalStrehovsky
Copy link
Member

but simply removing the second part of the if should probably fix it as well.

That would be a performance regression.

In the BCL we assume generic code over reference type can be shared and the AOT compiler generates it when the target is an obvious target of reflection like this.

Generic code over value types cannot be shared without performance regressions, which is why we fall back to just using reflection since it's going to be slower with AOT either way.

@steveisok
Copy link
Member

Also, why does this not occur for debug builds? I have a debug build in production in the AppStore right now (unfortunatly).

I believe interpreter should be on by default in debug builds, which is why it's working for you. I suspect that property is somehow not set in your release project. In interpreter mode, RuntimeFeature.IsDynamicCodeSupported becomes true.

@AbstractionsAs
Copy link
Author

@steveisok Even if RuntimeFeature.IsDynamicCodeSupported is somehow true, (!declaringType.IsValueType && !propertyType.IsValueType) will always be true (there are no value types), meaning that we will reach this code branch anyway...

Since this causes JIT, we can conclude that the premise that reference types will not cause JIT'ing is false...

@AbstractionsAs
Copy link
Author

@MichalStrehovsky Yeah, it will. But not working at all seems a greater regression.. I currently have debug builds in prduction, which is a much greater regression.

Since none of the types are values types (class, string), then the premise that reference types will not cause JIT'ing cannot hold.. Is it possible that there are some custom adaptations made elsewhere for strings (handling them a certain way) that means they behave differently from other reference types in this case?

@vargaz
Copy link
Contributor

vargaz commented Jan 27, 2023

Whats happening here is that the BCL is creating bound delegates, i.e. delegates with a null target, which when called, will make a virtual call to their bound method using their first argument as the receiver. Mono implements this using these 'invoke_callvirt_void_Element_string' wrapper methods generated at runtime. But since the wrapper methods depend on both the delegate type and the bound method to make the virtual call, they cannot be generated at AOT time since the AOT compiler can't determine that a particular combination of delegate type and bound method will be needed at runtime.

@AbstractionsAs
Copy link
Author

@vargaz But if the if had returned false, then it would have fallen back to reflection, and worked as expected, correct? Wouldn't that be the correct choice in this case?

@vargaz
Copy link
Contributor

vargaz commented Jan 27, 2023

Testcase:

using System;
using System.Runtime.InteropServices;

public class Tests
{
    public static void Main () {
        var del = (Func<string, string>)Delegate.CreateDelegate (typeof (Func<string, string>), null, typeof (object).GetMethod ("ToString"));
        Console.WriteLine (del ("FOO"));
    }
}

@MichalStrehovsky
Copy link
Member

Whats happening here is that the BCL is creating bound delegates, i.e. delegates with a null target, which when called, will make a virtual call to their bound method using their first argument as the receiver. Mono implements this using these 'invoke_callvirt_void_Element_string' wrapper methods generated at runtime.

For NativeAOT, we generate these ahead of time for each delegate type in the app. It costs some size, but the size is a fixed per-delegate overhead and this is guaranteed not to fail at runtime. For open instance delegates the generated thunk looks like this: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/TypeSystem/IL/Stubs/DelegateThunks.cs#L150-L227

There is extra code to initialize a new instance of such delegate properly. Delegates on CoreCLR-JIT and CoreCLR-AOT have 4 instance fields - their meaning is overloaded depending on what kind of delegate that is.

@vargaz
Copy link
Contributor

vargaz commented Jan 30, 2023

Looks like mono needs to do the same, i.e. resolve the called method pointer using an icall instead of hardcoding the called method into the wrapper.

@LeVladIonescu
Copy link
Contributor

LeVladIonescu commented Jan 30, 2023

@AbstractionsAs can you follow these steps https://learn.microsoft.com/en-us/visualstudio/ide/msbuild-logs?view=vs-2022 to create a detailed log for verifying that UseInterpreter is properly set to true for your Release build?
Furthermore, can you create a binlog file - https://github.com/xamarin/xamarin-macios/wiki/Diagnosis - when you build your project and share it here?

@LeVladIonescu
Copy link
Contributor

This should be fixed by #85643.
Please re-open it if you hit it after .Net8 Preview7.

@ghost ghost locked as resolved and limited conversation to collaborators Sep 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants