WinUI app' store version crashes after System.Text.Json.JsonSerializer is used

Hi @Hong ,

Thank you for isolating the behavior to the two JSON calls and sharing how the exception changed after cleaning the build output.

A separate System.Text.Json NuGet reference is not normally required for an app targeting .NET 10. Microsoft documents that the library is included in the shared framework from .NET Core 3.0 onward. A framework-dependent app uses an installed .NET runtime; a self-contained publish includes the runtime with the application. These deployment modes explain how the library can be available without an explicit package reference.

Adding the NuGet reference resolved the missing-assembly exception in your test. However, that result does not establish why the previous package could not resolve the assembly or which copy Debug was loading. I would keep the reference in place for now rather than remove it or manually copy framework DLLs.

Regarding the startup crash in your initial log, the ComInterfaceEntry exception occurs in GlobalVtableLookup.InitializeGlobalVtableLookup() during module initialization. It is different from the System.Text.Json missing-assembly exception reported in your update. Neither exception by itself proves that JSON reflection or trimming caused the failure.

For the next package test, please generate a fresh Release x64 package with the current references and deployment settings unchanged. Install it locally and test both saving and loading profiles, not only startup. This checks the packaged behavior without requiring another Store submission. If both operations now work, you can stop here; there is no need to change additional settings just to remove the explicit JSON reference.

If serialization still fails, inspect the Release configuration before changing the JSON code. Check PublishTrimmed, SelfContained, WindowsAppSDKSelfContained, and whether JsonSerializerIsReflectionEnabledByDefault is explicitly configured. Please check the effective values used by the build, including any publish-profile overrides, rather than relying on a single declaration in the project file. Leave these settings unchanged during this check.

Actual trimming during publish and the JSON reflection setting need to be distinguished. Microsoft documents that PublishTrimmed also affects features during build, and that enabling it disables default reflection-based JSON serialization unless explicitly overridden. Deployment mode alone does not establish whether reflection is enabled. Also, the .NET and Windows App SDK self-contained settings control separate dependencies.

For the JSON calls, source generation is the supported alternative if reflection-based serialization is disabled or you intend to keep trimming enabled. The documented reflection-disabled exception is InvalidOperationException, not either loader exception you posted. The code below addresses serialization; it is not a demonstrated fix for the ComInterfaceEntry or missing-assembly failure. If a loader exception is still preventing startup, please share the details requested at the end rather than making this code change to try to repair it.

To use it, add a context class in the same namespace as your existing ImageProfile model, with these imports. Keep your existing model rather than replacing it with a sample model:

using System.Collections.Generic;
using System.Text.Json.Serialization;

[JsonSourceGenerationOptions(GenerationMode = JsonSourceGenerationMode.Metadata)]
[JsonSerializable(typeof(List<ImageProfile>), TypeInfoPropertyName = "ImageProfiles")]
internal partial class ProfileJsonContext : JsonSerializerContext
{
}

This example uses metadata generation to support both serialization and deserialization.

At the existing save location, replace the serialization call with:

string json = System.Text.Json.JsonSerializer.Serialize(
    listProfiles, ProfileJsonContext.Default.ImageProfiles);

At the existing load location, replace the deserialization call with:

List<ImageProfile>? loadedProfiles = System.Text.Json.JsonSerializer.Deserialize(
    json, ProfileJsonContext.Default.ImageProfiles);

Keep your existing handling for a null result or invalid JSON. If ImageProfile uses polymorphism, object-typed values, custom converters, or non-public members, review its serialization contract before applying this unchanged. These requirements apply wherever the generated context is used, including Debug. Microsoft's source-generation guide describes the configuration requirements.

A standalone check using .NET SDK 10.0.401 and runtime 10.0.12, without a System.Text.Json package reference, passed a two-profile round trip using this context pattern in both untrimmed and trimmed self-contained Release builds. The trimmed reflection-based control produced the expected InvalidOperationException. This validates the JSON pattern with a simple model, not your WinUI package or the ComInterfaceEntry failure.

If you make this JSON change, keep the deployment settings and package versions unchanged, clean the affected projects' bin and obj build output, then create and locally install a fresh package. Test both save and load in Debug and in the installed Release package, not only startup.

If a loader exception remains, please share the current exception and stack, along with the relevant project and publish-profile sections with sensitive information removed. Please include TargetFramework, the System.Text.Json and Microsoft.WindowsAppSDK package versions, the version of any explicit Microsoft.Windows.CsWinRT reference, and the Release settings discussed above together with PublishAot. Those details will help focus the next check on runtime deployment and dependency resolution rather than assuming the serialization change will fix the loader failure.

Please try the applicable steps and let me know how they go. If you run into any difficulties, leave a comment with the step you tried and the resulting behavior or error, with sensitive information removed. I will do my best to help you work through the next steps.