Split UseMauiCommunityToolkit

[tranb3r]

My app is not using MCT Popup, but the whole Popup code cannot be trimmed from it, because when calling UseMauiCommunityToolkit, the popup service is registered for DI, so the trimmer cannot get rid of it.
More generally, MCT is a collection of features more or less independant from each others, so it's probably not a good idea to use a single intialization method, if we want the trimmer to be efficient.
To fix this problem, would you consider splitting UseMauiCommunityToolkit by feature (or feature group)? (UseMctPopup / UseMctConverters / UseMctViews ...)?
Or maybe there is a smarter way to do workaround this issue?

[pictos]

@tranb3r, the easy fix on your side is to not call the UseMauiCommunityToolkit and create your extension method to register the pieces that you will use, and of course, disable the analyzer to not block your build.

[tranb3r]

Of course. This works as a quick fix.

But this is not really satisfying, for several reasons:

• I have to make sure my code is synchronized with the official method.
• I cannot call MCT internal code (not a problem right now, but could be in the future).
• I'm probably not the only one facing this issue (without realizing it's an issue).

[bijington]

I suspect we might need to migrate to the approach that .NET MAUI uses where we don't auto register the PopupService with the DI layer. Initially I wanted to make it more difficult for developers to encounter issues where they hadn't registered the PopupService but supporting trimming will likely provide more value here. We have the standup tomorrow so I will see if I can get this added to the agenda.

[tranb3r]

I've watched the standup. Let me share my feedback and frustration:

• This question is not just about PopupService. It's about each feature in this Toolkit. Right now MCT is a monolith because of this UseMCT method, and I do not think it's a good design. MCT is basically just a collection of things.
• We're not talking about a 5kB optimization. When enabling AOT, LVVM, multiple architectures, it can be up to 100kB (or even more), especially when only using a small set of features.
• Users read documentations. MCT is the only plugin that tells the user where it has to put the UseMyPlugin line of code. This is useless and even a pain for users who want to register their plugins in an extension of the MauiAppBuilder. Breaking this analyzer should not be a blocker when talking about improvements.
• Users want small apps. This is not something new. We've been using the linker (in a xamarin or maui app) for years. Of course it requires fine tuning, sometimes from the lib owner, sometimes from the lib consumer, but the gain can be huge. MCT will have to support it officially in net9, but right now people are already using the trimmer, and not hearing that is a mistake.
• Our app has ~200 assemblies (framework + plugins), and we've looked at each one of them to make sure the code is properly trimmed. We've discussed this issue with many plugin owners, and helped them improve their code, in order to make sure we can decrease as much as possible our app size. They've taking this issue seriously, for years, as much as we are, and things have improved a lot. So why does MCT have a different approach to this issue?
• I regret you take this kind of decisions during your standup, instead of using github to discuss more with users and contributors. We are happy to share our needs and to contribute. We can understand a decision has to be taken, and we can understand a decision, assuming there has been a debate. But I sometimes have the feeling that some issues/discussions are closed without really listening to the users. Maybe I'm wrong, but to me, it kind of defeats the purpose of having a Community toolkit.

I don't want to be rude (and english not being my mother tongue does not help). I'm really thankful for the hard work (especially knowing that you're not paid by MS, as you keep repeating to everybody). I'm just sharing some frustration, and if by any chance somebody reads it, I'm happy to answer questions and help improve things as much as I can.

[tranb3r]

I'm pretty sure it won't work. It won't remove code inside of a method. It has to be a different method.
And again, adding new methods is not a breaking change...

[pictos]

I think you're wrong. Calling UseMCT from the app code will execute builder.Services.AddSingleton<IPopupService, PopupService>(), even if the app code does not use IPopupService and PopupService. So IPopupService and PopupService cannot be trimmed.

I can be wrong, but your reason is wrong as well. The linker doesn't know what the code will do because it doesn't run the code... It's due in compilation time, not runtime... So nothing is registered in DI because there's no DI in compilation time.

@tranb3r how do you get that dll is from obj or bin folder? If so I think that will not show what's removed or not

[tranb3r]

So nothing is registered in DI because there's no DI in compilation time

By "registered in DI" I meant having this kind of code in your code path: builder.Services.AddSingleton<IPopupService, PopupService>()
Of course the trimmer does not care about DI registration, all it sees is that your code path uses both the service interface and service class.
So the trimmer won't remove them. It's only removing the unused content (methods, properties) inside those interface/classes. Here, the constructor for PopupService is kept. And a few static stuff.

How do you get that dll? I think that will not show what's removed or not.

Of course you have to inspect the right assembly, the one after trimming.
Two options:

• obj\Release\net8.0-android34.0\android-arm64\linked\ folder (substitute whatever configuration/tfm you're using)
• from the assemblies folder in your apk. Just make sure you disable compression: AndroidUseAssemblyStore=false AndroidEnableAssemblyCompression=false

You also have to make sure to disable IL strip if you're using it: AndroidStripILAfterAOT=false

[tranb3r]

I also want to clarify one thing that maybe has been mis-inerpreted in my comments:

• when I say that a class is not trimmed, I mean that the class itself is kept, but its content might have been trimmed, so maybe the only thing that is left is the constructor, or some static properties.
• as opposed to a class that is totally removed by the trimmer, because the code is not referencing it at all.

[tranb3r]

We may add parameters (RegisterHandlers, RegisterServices) to UseMCT

Vlad, I'm not totally sure what you have in mind.
So just to clarify:

This won't work:

// --- MCT code
public void UseMCT(bool useFeatureA=true, bool useFeatureB=true)
{
    if (useFeatureA) UseFeatureA();
    if (useFeatureB) UseFeatureB();
}
private void UseFeatureA() {};
private void UseFeatureB() {};
// --- User code
UseMCT(useFeatureA=true, useFeatureB=false); // UseFeatureB method will not be trimmed

But, as I'm suggesting, this will work:

// --- MCT code
public void UseMCT()
{
    UseFeatureA();
    UseFeatureB();
}
public void UseFeatureA() {};
public void UseFeatureB() {};
// --- User code
UseFeatureA(); // not calling UseFeatureB so UseFeatureB method will be trimmed

[CliffAgius]

Discussed again on the Monthly stand-up for September and the community agreed this is something that would be nice but with limited resources not something we can progress at this time.

However we are a community and more than happy to accept a PR if you feel like jumping in. 😉

[tranb3r]

@CliffAgius @brminnick

I've listened to the stand-up and I want to clarify two things:

• I totally understand this is not high priority, this is only optimization. It does not mean this discussion has to be closed without agreeing on a design for future stuff. It would be so cool if each new feature added to MCT was implemented to be compliant with trimming. But for that we have to agree on a design, which you seem reluctant to do.
• I'm not asking you to implement anything, at the moment this is only a discussion, and of course I'm vocal about it, which means I'd be glad to contribute, although you're very strict about what you're accepting, so I must be sure we agree on what I'd do before starting a PR.

Here is a PR, very simple, because right now I only need NavigationBar in my app.
Let me know what you think about it.
#2185