Workload 8.0.61 breaks Mono interpreter on MacCatalyst.

[jdngray77]

Description

This week, our build inexplicably broke.

It started producing copies of our app which were not capable of talking to the server and instead produced runtime exceptions. See output below.

We identified the cause to be the Mono interpreter no longer functioning correctly, failing to handle dynamically generated code used in our web interface.

We understand that dynamically generated code has limitations on MacCatalyst, and so in accordance to the docs we have always enabled the Mono interpreter with <UseInterpreter>true</UseInterpreter>.

We've tried downgrading to SDK version 8.0.302 with no effect, and using <MtouchInterpreter>all</MtouchInterpreter> in place of UseInterpreter also to no effect.

This seems to be a fault that was introduced with an update in the MAUI workload, from 8.0.40 at the start of this week (W/C 8th july 2024) to 8.0.61.

Downgrading with the use of a rollback file to 8.0.40 restores our build artefacts functionality : dotnet workload install maui-maccatalyst --from-rollback-file https://maui.blob.core.windows.net/metadata/rollbacks/8.0.40.json

Steps to Reproduce

1. Checkout the repro below
2. Restore workload 8.0.61
3. Clean & Build
4. Observe that when the button is clicked, PlatformNotSupportedException is written to the console.
5. Restore workload 8.0.40
6. Clean & Build
7. Observe that when the button is clicked, dynamically generated code writes "Hello, Reflection.Emit!" to the console.

Link to public reproduction project repository

https://github.com/jdngray77/MauiReproEmit

Version with bug

8.0.61 SR6.1

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.40 SR5

Affected platforms

macOS

Affected platform versions

Sonoma 14.5 (23F79)

Did you find any workaround?

Yes.

Edit:

1. As per the comments; Replacing <UseInterpreter>true</UseInterpreter> with <MtouchInterpreter>all</MtouchInterpreter>

2. We can use a rollback file to restore an older MAUI workload, prior to the issue being introduced

dotnet workload install maui-maccatalyst --from-rollback-file https://maui.blob.core.windows.net/metadata/rollbacks/8.0.40.json

Relevant log output

Exception Type: System.PlatformNotSupportedException
Exception Message: PlatformNotSupported_ReflectionEmit
Stack Trace:    at System.Reflection.Emit.AssemblyBuilder.ThrowDynamicCodeNotSupported()
   at System.Reflection.Emit.AssemblyBuilder.EnsureDynamicCodeSupported()
   at System.Reflection.Emit.RuntimeAssemblyBuilder..ctor(AssemblyName , AssemblyBuilderAccess )
   at System.Reflection.Emit.AssemblyBuilder.DefineDynamicAssembly(AssemblyName , AssemblyBuilderAccess )
   at System.Reflection.DispatchProxyGenerator.ProxyAssembly..ctor(AssemblyLoadContext )
   at System.Reflection.DispatchProxyGenerator.<>c.<CreateProxyInstance>b__6_0(AssemblyLoadContext x)
   at System.Runtime.CompilerServices.ConditionalWeakTable`2[[System.Runtime.Loader.AssemblyLoadContext, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.Reflection.DispatchProxyGenerator.ProxyAssembly, System.Reflection.DispatchProxy, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]].GetValueLocked(AssemblyLoadContext , CreateValueCallback )
   at System.Runtime.CompilerServices.ConditionalWeakTable`2[[System.Runtime.Loader.AssemblyLoadContext, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.Reflection.DispatchProxyGenerator.ProxyAssembly, System.Reflection.DispatchProxy, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]].GetValue(AssemblyLoadContext , CreateValueCallback )
   at System.Reflection.DispatchProxyGenerator.CreateProxyInstance(Type , Type , String , String )
   at System.Reflection.DispatchProxy.Create[WebServiceSoap,ServiceChannelProxy]()
   at System.ServiceModel.Channels.ServiceChannelProxy.CreateProxy[WebServiceSoap](MessageDirection direction, ServiceChannel serviceChannel)
   at System.ServiceModel.Channels.ServiceChannelFactory.CreateProxy[WebServiceSoap](MessageDirection direction, ServiceChannel serviceChannel)
   at System.ServiceModel.Channels.ServiceChannelFactory.CreateChannel[WebServiceSoap](EndpointAddress address, Uri via)
   at System.ServiceModel.ChannelFactory`1[[XXX.XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].CreateChannel(EndpointAddress address, Uri via)
   at System.ServiceModel.ChannelFactory`1[[XXX.XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].CreateChannel()
   at System.ServiceModel.ClientBase`1[[XXX.XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].CreateChannel()
   at System.ServiceModel.ClientBase`1[[XXX.XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].CreateChannelInternal()
   at System.ServiceModel.ClientBase`1[[XXX.XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].get_Channel()
   ...

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• iOS Release build crashing. (#22173), similarity score: 0.75
• UseInterpreter is set in any project referencing a class library that references MAUI (#21653), similarity score: 0.72

Closed similar issues:

• MacCatalyst project fails to build with clang++ error after migrating to .NET 8 (#18741), similarity score: 0.75
• .NET 8.0.10 breaks MAUI builds (#21170), similarity score: 0.73
• [regression/8.0.0-preview.7.8842] System.TypeLoadException with .NET 8 (#17136), similarity score: 0.71

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[timlajaunie]

We're experiencing the same with iOS targets. The rollback workaround does not appear to be possible when workload 8.0.61 is installed by multiple sources, such as the SDK and Visual Studio in Windows.

[PureWeen]

@rolfbjarne ?

[ivanpovazan]

/cc: @BrzVlad

[ninachen03]

This issue has been verified using Visual Studio 17.16.12 (build 410)(8.0.61). Can be reproduced

[BrzVlad]

On the new version, the runtime config json explicitly sets "System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported": false. The previous, working version, was not declaring this property at all, so it was defaulting to true at run time. I'm not familiar where exactly this configuration file is generated, but so far the issue seems to be within the build tasks.

Looks like the build starts with DynamicCodeSupport set to false.

[dalexsoto]

@kotlarmilos is this the result of xamarin/xamarin-macios#20687 ?

[ivanpovazan]

@dalexsoto I think the problem is introduced with this change: xamarin/xamarin-macios@a72bb30

MtouchInterpreter should inherit the value from UseInterpreter but the order of evaluation for MtouchInterpreter seems to be wrong. From the build log we can see that Xamarin.Shared.Sdk.targets gets imported before Xamarin.Shared.props. The former uses the value of MtouchInterpreter to determine DynamicCodeSupport setting. However, the UseInterpreter inheritance is determined in the latter props file, which causes the wrong value for DynamicCodeSupport to be set.

---

@jdngray77 could you please try again building/running your repro project by adjusting it in the following way:

<!-- <UseInterpreter>true</UseInterpreter> -->
<MtouchInterpreter>all</MtouchInterpreter>

I was able to execute your sample successfully with the mentioned change.

[edetoc]

@ivanpovazan I just tried the workaround you mentionned above with the sample @jdngray77 provided. Tried it for iOS. I confirm this workaround works with MAUI workload 8.0.61.

[jdngray77]

@ivanpovazan Verified here also, MTouchInterpreter resolves dynamic code generation both the repro and in our production repo using workload 8.0.61. Apologies; perhaps my testing with it before was too superficial to see results.

[giorgitedi]

I tried setting <MtouchInterpreter>all</MtouchInterpreter> and it also worked for us but previously we were using <MtouchInterpreter>-all</MtouchInterpreter> to AOT compile all assemblies.

What if we want to continue using AOT? because as described here "App execution speed will be slower because interpreted code runs more slowly than AOT compiled code."

[ivanpovazan]

@PureWeen FYI: xamarin/xamarin-macios#20912 (comment)