RuntimeInstanceNotAllowed Error Initializing XmlSerializer on Android Release Build in .NET 9

[david-maw]

Description

App fails with an exception in a release build of .NET 9 (.NET 8 and debug builds of .NET 9 work fine).

It looks like the fault happened because of a call on new XmlSerializer(typeof(Meal)) (deferring that call defers the fault).

The abbreviated stack trace looks like this:

System.ArgumentException: RuntimeInstanceNotAllowed
  ?, in object DefaultValueAttribute.get_Value()
  ?, in new XmlAttributes(ICustomAttributeProvider)
  ?, in XmlAttributes XmlReflectionImporter.GetAttributes(MemberInfo)
  ?, in bool XmlReflectionImporter.InitializeStructMembers(StructMapping, StructModel, bool, string, RecursionLimiter)
  ?, in StructMapping XmlReflectionImporter.ImportStructLikeMapping(StructModel, string, bool, XmlAttributes, RecursionLimiter)
...
(1 additional frame(s) were not displayed)

System.InvalidOperationException: XmlTypeReflectionError, DivisiBill.Models.Meal
  ?, in XmlSerializer Meal.get_MealSerializer()
  ?, in void Meal.SaveToStream(Stream streamParameter)
  ?, in void Meal.SaveToApp()
  ?, in void Meal.OverwriteCurrent()
  ?, in async Task Meal.BecomeCurrentMealAsync()
...
(12 additional frame(s) were not displayed)

Steps to Reproduce

1. Clone the repository, pull the class-constructor-fault branch.
2. Start VS2022 and select the DivisiBill project and a release build.
3. At the VS developer PowerShell prompt enter dotnet restore
4. Run the app without debugging on an Android Emulator or physical device (ctrl+F5). You should see:
   5.Then
   6.Press the left arrow to see:
5. Click "While Using the App" and see:
6. At this point the app will fault.

If it were working correctlyyou would see:
Then

Link to public reproduction project repository

https://github.com/david-maw/DivisiBill.git

Version with bug

9.0.0-rc.2.24503.2

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.93 SR9.3

Affected platforms

Android

Affected platform versions

Android 14

Did you find any workaround?

No response

Relevant log output

[drasticactions]

I don't believe your issue is related to the MAUI UI framework, it's a runtime one:

https://github.com/dotnet/runtime/blob/release/8.0/src/libraries/System.Private.CoreLib/src/System/ComponentModel/DefaultValueAttribute.cs

https://github.com/dotnet/runtime/blob/release/9.0/src/libraries/System.Private.CoreLib/src/System/ComponentModel/DefaultValueAttribute.cs#L246-L257

Between 8.0 and 9.0, a switch was added (#100416 and #105766) to throw on these values. Most likely what's tripping it up on Release mode is trimming (which would explain it working in Debug mode, and not Release.) I'm not sure how to specifically handle trimming with XmlSerializer, @jonathanpeppers would you know of what to do here?

[vitek-karas]

@LakshanF @sbomer - this is due to the addition of System.ComponentModel.DefaultValueAttribute.IsSupported feature switch and it being disable by default when trimming is enabled. I don't remember what's the story around this (I know that it was difficult to make it work with trimming/AOT), and if there are work arounds/solutions for the user.

[sbomer]

Minimal repro:

using System.Xml.Serialization;
using System.ComponentModel;

var s = new XmlSerializer(typeof(C));

_ = new C().T; // Prevent C.T from being removed by trimming

public class C {
    [DefaultValue(typeof(C), "c")]
    public Type T { get; }
}

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishTrimmed>true</PublishTrimmed>
  </PropertyGroup>
</Project>

This is currently by design - the ctor of DefaultValueAttribute that takes a type and a string is not trim compatible. We don't have a model for annotating attributes (annotating this constructor with RequiresUnreferencedCode would warn on every attribute instance, not the places that reflect over the attributed members), so we introduced the throwing behavior when trimming.

Note that in this example the use of XmlSerializer produces trim warnings.

It's possible to disable the throwing behavior by setting <_DefaultValueAttributeSupport>true</_DefaultValueAttributeSupport>, but note that this is not a supported configuration.

Most likely what's tripping it up on Release mode is trimming (which would explain it working in Debug mode, and not Release.)

Is it correct that the app was working in Debug mode? These settings should result in the same behavior whether you're in Debug or Release mode, so that might be a bug.

[david-maw]

Yes, the app works in Debug mode but I thought the code would not be trimmed in a debug build.

I'm not aware of any trim warnings in the repro I provided, and I typically treat warnings as errors, so while it is possible I missed one it seems unlikely.

On the face of it, if DefaultValue and PublishTrimmed are incompatible it seems like something stronger than a warning is needed, since the result is code that works in .NET 8 but not .NET 9. That said,

I think what you've written means that to operate in a supported configuration I must eliminate uses of DefaultValue or set PublishTrimmed false in the build, is that correct?

[sbomer]

@jonathanpeppers I'm aware that we made some changes to the trimming defaults for android recently - are both Debug and Release builds getting the defaults set by the illink targets?

As far as I understand, android doesn't show trim warnings unless using <TrimMode>full</TrimMode>. I think if you set that you should see the warnings.

I think what you've written means that to operate in a supported configuration I must eliminate uses of DefaultValue or set PublishTrimmed false in the build, is that correct?

Instances of DefaultValueAttribute won't cause problems unless something looks for them - so to be supported you would need to eliminate uses of code that depends on them (like XmlSerializer which is not trim-compatible).

[david-maw]

Given that I need to serialize and deserialize XML and tell the XML serializer not to serialize some properties if they have their default value, it seems like my only option is to use XmlSerializer and DefaultValue and turn off trimming.

Does that seem like it would work (albeit at the cost of a larger compiled app) and is there some other method that I'm missing to achieve the same XML serialization behavior?

I checked and <TrimMode>full</TrimMode> does indeed trigger a warning when DefaultValue is used, but the failure happens even without setting it, so a more aggressive warning is probably needed so as to avoid failures with no warning.

[sbomer]

Does that seem like it would work (albeit at the cost of a larger compiled app) and is there some other method that I'm missing to achieve the same XML serialization behavior?

That may work (I'm not sure how well supported it is to disable trimming entirely in an android app) - but it sounds like you are mainly interested in compat with the .NET 8 behavior, so I would recommend setting _DefaultValueAttributeSupport. We are considering taking a fix for .NET 9 that would preserve this behavior with <TrimMode>partial</TrimMod>.

[david-maw]

I'm mainly interested in the ability to omit default valued items from XML serialization, I'd prefer it be done as it was in .NET 8 just because that's less work for me, but if there's a preferred method, I can probably convert to using that.

I'd shied away from DefaultValueAttributeSupport because of the earlier comment that it was not a supported configuration, but it seems to work on my code, so thank you.

That means I have a workaround for my instance of the problem but there remains a situation where code that worked fine on NET 8 receives no warnings and appears to work fine on NET 9, right up until you try an Android release build, then it fails. I'd suggest at the very least a warning, so users who may fall afoul of this get a hint that all may not be well.

[vitek-karas]

We are definitely planning to fix the apparent breaking change between 8 and 9 - thanks a lot for spotting this and filing an issue!

Note that the partial trim mode which is the default for MAUI apps doesn't make hard guarantees about trim compatibility. It tends to work in most cases, but there's definitely ways where you can get it to break. That has been like that since a long time ago (goes back to Xamarin).

The full trim mode on the other hand does make guarantees, but it also produces lot of trim related warnings. If there are warnings, the app may break. If there are no warnings it will work (if not, it's a bug). In .NET 9 we've made lot of improvements to MAUI to make at least the core of MAUI trim compatible, so that a simple app in MAUI doesn't produce any warnings and thus can work with full trimming. Larger apps tend to depend on lot of additional components all of which need to be compatible with trimming for this to work - getting the ecosystem adapted to trimming is a long journey though.

[vitek-karas]

@matouskozak could you please look into preparing a fix for the breaking change?

In short - we should set DefaultValueAttributeSupport to true for mobile targets if in partial trim mode. Similar to how we enable reflection based JSON serialization in that case. We should also check what happens in WASM (I suspect it's going to be a similar problem to mobile).