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

Workload 8.0.61 breaks Mono interpreter on MacCatalyst. #23577

Closed
jdngray77 opened this issue Jul 12, 2024 · 12 comments · Fixed by xamarin/xamarin-macios#20912
Closed

Workload 8.0.61 breaks Mono interpreter on MacCatalyst. #23577

jdngray77 opened this issue Jul 12, 2024 · 12 comments · Fixed by xamarin/xamarin-macios#20912
Assignees
Labels
i/regression This issue described a confirmed regression on a currently supported version partner/macios Issues for the Mac / iOS SDK platform/macOS 🍏 macOS / Mac Catalyst potential-regression This issue described a possible regression on a currently supported version., verification pending s/triaged Issue has been reviewed s/verified Verified / Reproducible Issue ready for Engineering Triage t/bug Something isn't working
Milestone

Comments

@jdngray77
Copy link

jdngray77 commented Jul 12, 2024

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>
  1. 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()
   ...
@jdngray77 jdngray77 added the t/bug Something isn't working label Jul 12, 2024
Copy link
Contributor

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:

Closed similar issues:

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

@timlajaunie
Copy link

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
Copy link
Member

@rolfbjarne ?

@ivanpovazan
Copy link
Member

/cc: @BrzVlad

@ninachen03 ninachen03 added s/verified Verified / Reproducible Issue ready for Engineering Triage s/triaged Issue has been reviewed labels Jul 15, 2024
@ninachen03
Copy link

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

@BrzVlad
Copy link
Member

BrzVlad commented Jul 15, 2024

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.

@samhouts samhouts added platform/macOS 🍏 macOS / Mac Catalyst potential-regression This issue described a possible regression on a currently supported version., verification pending labels Jul 15, 2024
@dalexsoto
Copy link
Member

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

@ivanpovazan
Copy link
Member

ivanpovazan commented Jul 16, 2024

@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.

Screenshot 2024-07-16 at 18 45 57

@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.

@samhouts samhouts added partner/macios Issues for the Mac / iOS SDK i/regression This issue described a confirmed regression on a currently supported version and removed potential-regression This issue described a possible regression on a currently supported version., verification pending labels Jul 16, 2024
@edetoc
Copy link

edetoc commented Jul 16, 2024

@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
Copy link
Author

@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
Copy link

giorgitedi commented Jul 17, 2024

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
Copy link
Member

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
i/regression This issue described a confirmed regression on a currently supported version partner/macios Issues for the Mac / iOS SDK platform/macOS 🍏 macOS / Mac Catalyst potential-regression This issue described a possible regression on a currently supported version., verification pending s/triaged Issue has been reviewed s/verified Verified / Reproducible Issue ready for Engineering Triage t/bug Something isn't working
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.