.NET 9 MAUI trimming is documented here: .0.

After going through all the recommendations for trimming what happens if you publish and find that the app is not working 100%? Is there a way to do the equivalent of dotnet publish for a debug build on your local development machine so you can more easily capture when errors /exceptions are happening?

Interested primarily in the context of developing in Visual Studio on Windows.

Here's an example where it's possible to miss something. Using Json.Net I have a custom JsonConverter where there is an override of the ReadJson method. This override makes use of Activator.CreateInstance so is flagged by the compiler with the IL2091 warning. But the DynamicallyAccessedMembers that would normally be added to remove the warning cannot be added because it causes the method definition to differ from the base. The only choice is to disable the warning, try to make sure the needed types are preserved, and verify with testing at runtime.

It's the "testing at runtime" cycle that I'm trying to improve by getting runtime diagnostics that can help point out what Type is missing.

.NET 9 MAUI trimming is documented here: https://learn.microsoft/en-us/dotnet/maui/deployment/trimming?view=net-maui-9.0.

After going through all the recommendations for trimming what happens if you publish and find that the app is not working 100%? Is there a way to do the equivalent of dotnet publish for a debug build on your local development machine so you can more easily capture when errors /exceptions are happening?

Interested primarily in the context of developing in Visual Studio on Windows.

Here's an example where it's possible to miss something. Using Json.Net I have a custom JsonConverter where there is an override of the ReadJson method. This override makes use of Activator.CreateInstance so is flagged by the compiler with the IL2091 warning. But the DynamicallyAccessedMembers that would normally be added to remove the warning cannot be added because it causes the method definition to differ from the base. The only choice is to disable the warning, try to make sure the needed types are preserved, and verify with testing at runtime.

It's the "testing at runtime" cycle that I'm trying to improve by getting runtime diagnostics that can help point out what Type is missing.

• visual-studio
• -core
• maui

• 1 The trimmer produces trim warnings when it finds code that might not be compatible with trimming. These warnings should be fixed, and the app should be thoroughly tested after trimming to ensure no behavior changes. – Guangyu Bai - MSFT Commented Mar 4 at 8:30
• @GuangyuBai-MSFT Thanks for the idea. I've removed all compile time warnings from a Rebuild All, including those related to trimming that appeared when trimming was set to full in the project. I'm trying to do the "thorough testing" now and looking for tips to speed up that build and diagnostic process for observed issues. – DennisWelu Commented Mar 4 at 18:24
• It's great to hear that you've removed all compile-time warnings and are now focusing on thorough testing. – Guangyu Bai - MSFT Commented Mar 5 at 9:49
• @DennisWelu keep in mind that you can make another "project type", an alternative to Debug and Release, so that you can try different combinations of settings. There might be a sweet spot between those two, that speeds up deployment (compared to Release), but includes Trimming and perhaps some other Release settings. – ToolmakerSteve Commented Mar 9 at 0:30
• The "thorough testing" is the challenge. In the case of iOS right now that involves having application insights plugged in to the app, doing a full build and upload to Test Flight, running the app to trigger issues, and reviewing the exceptions logged in application insights. Not great. I would like to do this locally but simply building/deploying a Release mode build is not enough. – DennisWelu Commented Apr 1 at 13:09

1 Answer 1

Temporarily add <PublishTrimmed>true</PublishTrimmed> to your csproj.

Then you can at least do a local build and skip the need to publish and deploy through Test Flight etc. Even though the Trim a .Net MAUI app documentation says

you temporarily can set it true to force the issue on local Release builds.

I did not have any success catching exceptions locally or getting nice logging in the Output window. Even adding symbol generation and disabling optimizations in the Release configuration would not help. Still had to rely on exceptions logged to the integrated Application Insights service. Maybe will get that figured out and then will expand further on this partial answer.