[X] Improve warnings when binding cannot be compiled

[simonrozsival]

Description of Change

In #19360 we introduced a warning that's reported when XamlC cannot compile a binding because we don't know the data type of the source (x:DataType is missing). To make this warning less confusing to customers, I suggest adding a link to the docs so that it is immediately clear how to improve the code to address the warning.

Also, it might be worth hiding these warnings unless developers opt-in to a "XamlC strict mode". This should be the default for NativeAOT and in .NET 9 it could be the default for all apps. To make migration from Xamarin.Forms easier, we might want to hide these warnings in the next .NET 8 servicing release.

Issues Fixed

Based on feedback in #21277

/cc @StephaneDelcroix @davidortinau

[bcaceiro]

As a suggestion, for newcomers, a performance improvement tip would be better ( I know it is in the links), but it is a better call to action for developers. everyone wants performance :)

[StephaneDelcroix]

if we're providing the link for help, we should also make the warning clickable on VS, by supporting HelpLink

[simonrozsival]

@balachir thanks for the suggestion

@PureWeen @jonathanpeppers @StephaneDelcroix I suggest adding a $(MauiXamlCStrictMode) which only defaults to true on NativeAOT (and later possibly also for trim mode full). Unless the strict mode is enabled, we wouldn't warn about missing x:DataType.

[rmarinho]

/rebase

[StephaneDelcroix]

shouldn't it add the exceptions to WarningsNotAsErrors instead of NoWarn, so the warnings will still be displayed ?

[simonrozsival]

@StephaneDelcroix I think it might be better to completely hide the warnings in .NET 8 to decrease friction for customers migrating from Xamarin.Forms.

[StephaneDelcroix]

@StephaneDelcroix I think it might be better to completely hide the warnings in .NET 8 to decrease friction for customers migrating from Xamarin.Forms.

Maybe warning are too harsh, but hiding them will only defer the friction till .NET9 is release. What do you think about logging them as 'Message', like <WarningsAsMessage>XC0022;XC0023</WarningsAsMessage>, and adding a WarningsAsMessage parameter to the Task ?

[simonrozsival]

@StephaneDelcroix would that even be printed to the log (especially with the new msbuild terminal logger)? Wouldn't the messages only be visible in binlogs? At that point, isn't it better to skip the logs altogether?

[simonrozsival]

@StephaneDelcroix I reverted the changes that disable the warnings for now. I suggest we merge the updated warning message and I'll open a separate PR where we can continue the discussion whether to disable those warnings or not.