Add Obsolete attribute to MessagingCenter

[jfversluis]

Description of Change

First step in deprecating MessagingCenter. There are already multiple issues/discussions ongoing (see below) about what we should do here. But I think we all agree that MessagingCenter does not really have a place in a UI framework. I think we should take this earliest opportunity to deprecate it and recommend our users an alternative.

As a next step, which is probably .NET 8, at the very least we can internalize the APIs. That way we can still leverage it ourselves. Ideally I think we would want to not rely on a messenger at all or switch to a different, more performant messenger. We are considering the one in the CommunityToolkit.MVVM, but that means taking a dependency on a MVVM framework which is probably not desirable.

There are currently no plans to separate the messenger from CommunityToolkit.MVVM into a seperate package.

Also see:

• Leverage `CommunityToolkit.MVVM` Messenger #3797
• Proposal - Replace internal use of MessagingCenter  #3880

Issues Fixed

N/A

[jsuarezruiz]

Need to update some places where we use the MessagingCenter to avoid the build errors. Mostly all the changes are in the AlertManager classes.

/Users/builder/azdo/_work/2/s/src/Controls/src/Core/Platform/AlertManager/AlertManager.iOS.cs(68,5): error CS0618: 'MessagingCenter' is obsolete: 'We recommend migrating to `CommunityToolkit.MVVM.WeakReferenceMessenger`: https://www.nuget.org/packages/CommunityToolkit.Mvvm' [/Users/builder/azdo/_work/2/s/src/Controls/src/Core/Controls.Core.csproj]
/Users/builder/azdo/_work/2/s/src/Controls/src/Core/Platform/AlertManager/AlertManager.Tizen.cs(64,4): error CS0618: 'MessagingCenter' is obsolete: 'We recommend migrating to `CommunityToolkit.MVVM.WeakReferenceMessenger`: https://www.nuget.org/packages/CommunityToolkit.Mvvm' [/Users/builder/azdo/_work/2/s/src/Controls/src/Core/Controls.Core.csproj]

[hartez]

Instead of putting pragmas in dozens of places, why don't we wait until we've got a replacement for MC internally? Then we can just mark two things Obsolete and be done with it.

[jfversluis]

I'd be happy to, but realistically, when do we see that happening? Before .NET 7? If not, the deprecation won't happen until .NET 8 and removal not until .NET 9 which is still a long time in the future if you ask me. At least now we will have the deprecation in place and we can start working on internal bits from there.

I guess an easy sort of workaround is to duplicate MC to something internal already as-is and start using that at least to prevent all the pragmas everywhere?

[hartez]

I'd be happy to, but realistically, when do we see that happening? Before .NET 7? If not, the deprecation won't happen until .NET 8 and removal not until .NET 9 which is still a long time in the future if you ask me. At least now we will have the deprecation in place and we can start working on internal bits from there.

In a perfect world, yes, we'll have a good replacement option for MAUI which we can also recommend to our users before .NET 7. But that's not likely; the .NET 8 timeline is more realistic.

But what good does it do the users for us to obsolete MC if we don't have a good recommendation for a replacement?

Us: "This is obsolete; we're going to stop using it, and you should, too."
Them: "Cool, what should we use instead?"
Us: [shrugs]

[michael-hawker]

@hartez the recommendation already exists in the MVVM Toolkit. This is about getting folks to know about it (as mentioned in the Obsolete message itself here: https://github.com/dotnet/maui/pull/8765/files#diff-bb9ccb728be14f1034af1e24e4a8aba04b8d2563fac228fafb3c7135b58eca81R24)

The rest of the work is in #3880 to use that internally so the code can be removed.

It'd be best to get the messaging in .NET 7 and remove in .NET 8 as .NET 8 is the long-term servicing build so it means the messaging center code wouldn't be sticking around even longer than it should.

[hartez]

Okay, I've changed my mind on this - I think we should just go ahead and do it.