MddBootstrapAutoInitializer does not compile with enabled ImplicitUsings

[HavenDV]

Servicing bug (1.0): https://task.ms/38083595

Bug with the intersection of Microsoft.WindowsAppSDK.Runtime.Version with System.Version.

It needs to use global:: prefixes.

Env:
Microsoft.WindowsAppSDK: 1.0.0-preview3
WindowsPackageType: None

[HavenDV]

Workaround: Create Fix.cs with this content

// Workaround for https://github.com/microsoft/WindowsAppSDK/issues/1686
global using Version = Microsoft.WindowsAppSDK.Runtime.Fix.Version;

namespace Microsoft.WindowsAppSDK.Runtime.Fix;

public class Version
{
    public const ushort Major = 0;
    public const ushort Minor = 319;
    public const ushort Build = 455;
    public const ushort Revision = 0;
    public const ulong UInt64 = 0x0000013F01C70000;
    public const string DotQuadString = "0.319.455.0";
}

[riverar]

Am confused. You turned on implicit usings which brought together two disparate namespaces and a type collided (as expected). How is this Windows App SDK's fault?

[HavenDV]

It adds the file to compile like a generator.

[HavenDV]

Please see PR

[riverar]

I'm not confused about the changes you made. I'm just trying to understand what problem implicit usings solves and why you think Windows App SDK should support this.

[HavenDV]

As far as I know, they will be enabled by default for new net6 projects.

[riverar]

That decision appears to have been reversed. https://devblogs.microsoft.com/dotnet/announcing-net-6-release-candidate-2/#net-sdk-c-project-templates-modernized

As part of the initial templates update, we enabled implicit usings by default (AKA opt-out) for .NET 6 (net6.0) projects (including if you updated an app from .NET 5 to .NET 6). That has been changed. We’ve updated the SDK so that all the new features are opt-in.

[HavenDV]

I mean, not at the SDK level, but when creating a new project, the MSBuild property ImplicitUsings will be set to true in the csproj file.
I'm not sure about this, but I believe you shouldn't have any overlaps with the System namespaces anyway.

[HavenDV]

It seems it was not included in the 1.0.0 stable release. I still get an error if I don't apply the workaround

[DrusTheAxe]

https://task.ms/38083595 for 1.0-servicing