protect maui xmlns from overloading

[StephaneDelcroix]

using XmlnsDefinition attribute, one can extend any xmlns. To avoid name collisions with common types, that would make disambiguation impossible, we need to protect http://schemas.microsoft.com/dotnet/2021/maui to well-known clr-namespaces

[etvorun]

@StephaneDelcroix can you please elaborate why protecting default MAUI xmlns is needed?

The "ambiguous types" issue is not specific to default xmlns. XAML compiler needs to handle such cases and produce meaningful errors (btw we need to create a tracking issue for that). That should be sufficient for in-house dev teams. Then it is extremely unlikely that 3rd party control vendors will ship their products containing "ambiguous types". It will not pass their quality control gates.

[StephaneDelcroix]

@etvorun it's very likely that

• 2 third party vendor define types with a common name (control or base type, like 'Point' or 'Color')
• your app project contains type with conflicting names with maui
• you copy over some source of a control, to make a modification

if you start overloading the maui xmlns, when there's a conflict, you can pick the other control, but not the one from maui

[etvorun]

I would expect that XAML compiler would generate "ambiguous types" error. Default xmlns or not. Am I correct (at least for non-default xmlns)?

[BretJohnson]

I would expect that XAML compiler would generate "ambiguous types" error. Default xmlns or not. Am I correct (at least for non-default xmlns)?

Do we know how WPF handles this?

[etvorun]

WPF does not handle it. I created WPF app and two WPF libraries, each containing

[assembly: XmlnsDefinition("http://consoto.com", "Consoto")]
namespace Consoto
{
    public class MyButton : Button {}
}

Then in MainWindow.xaml I added

<Window ... xmlns:lib="http://consoto.com">
  <Grid>
    <lib:MyButton  />
  </Grid>
</Window>

One library set background to red and another to green. So that I can tell which button is used. No build errors. WPF picks first found type. Funny enough, the picked types are different for XAML designer (red) vs runtime (green).

FWIW adding handling of ambiguous types in VS should be relatively easy.

[StephaneDelcroix]

I would expect that XAML compiler would generate "ambiguous types" error

XAML inflator will, yes. Build error for Xaml files that are compiled using XamlC, runtime error for the others

[etvorun]

Build error for Xaml files that are compiled using XamlC, runtime error for the others

Not sure I understand. It sounds like there are two XAML compilers. One for build time and another for runtime. I would expect that build time compiler produces build errors and runtime one throws exceptions. Default xmlns or not.