Fully qualify types in code generated by markup compiler

[miloush]

Fixes #7173 (verified) #7125 (verified) and likely #4014 (asked for repro)

Description

While XAML compiler treats types as fully qualified, the generated code behind does not use fully qualified types. As a result, language compilers can misinterpreted where a type should come from.

This PR fixes the issue by fully qualifying all types used in generated code that is placed in user namespace, using global alias. Notably, code in XamlGeneratedNamespace is not affected (apart from attributes), since it is a root namespace on its own and no usings are added.

Customer Impact

Not taking this fix makes it impossible to use WPF in namespace hierarchies where a subnamespace name is also a root namespace name.

Regression

No.

Testing

Built and compiled the repro projects provided. Ensured that applications using IComponentConnector, IStyleConnector and splash screen compile and run for both C# and VB.NET.

I am assuming the markup compiler is covered by tests (functional rather than textual). If that is not the case, let me know and we need to create some.

Risk

Medium.

First, it is a breaking change in the sense that there was a hypothetical possibility that someone could have injected their own replacements of System.* types into the generated code, taking advantage of the current behavior. This would no longer work, but I believe that risk is minimal as the types would not be recognized as compatible by the type binding system.

Generated code will be more verbose, consuming more space. The change affects the build process of everything and should any errors be introduced, developers will most likely be unable to workaround them.

On the plus side, the fix only enforces intended semantics of the XAML compiler, it is not meant to change any existing behavior.

Review notes

For correctness, it is mostly about whether some instances where a global alias should have been used were forgotten. These would not be found by testing currently compiling applications, but also they could be fixed easily subsequently.

For VB.NET, additional issues are caused by the default namespace that needs to be added to types before a global alias can be used. While I cannot think of a C# situation where this PR would break things that already worked, it is definitely a possibility for VB.NET due to the default namespace. It would be good to get as much of the VB.NET community as possible to check real-world projects compile as expected.

Try it out!

For anyone who wants to try this without building WPF themselves: Set a location to the dll in PresentationBuildTasks.zip using _PresentationBuildTasksAssembly property in the project file, e.g.

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net7.0-windows</TargetFramework>
    <RootNamespace>DELwpfVB7</RootNamespace>
    <UseWPF>true</UseWPF>
    <_PresentationBuildTasksAssembly>....path....\PresentationBuildTasks.dll</_PresentationBuildTasksAssembly>
</PropertyGroup>

(or globally instead of the property, backup and replace the assembly in the directory of your SDK, e.g. C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.Sdk.WindowsDesktop\tools\net472\PresentationBuildTasks.dll)

Microsoft Reviewers: Open in CodeFlow

[miloush]

/cc @Perpete @A-Badry @clairernovotny @Nukepayload2 @VBAndCs who participated in this repo in the past in a way that suggested they build VB.NET WPF applications - it would be great if you could check your projects compile fine using this build tasks assembly!

[CyrusNajmabadi]

Any tests that show what is generated here?