MTP incorrecrtly creates namespaces based on project name

[agocke]

Here's a simple example with SelfRegisteredExtensions:

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by Microsoft.Testing.Platform.MSBuild
// </auto-generated>
//------------------------------------------------------------------------------

namespace System.Security.Cryptography.ProtectedData.Tests
{
    [global::System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage]
    internal static class SelfRegisteredExtensions
    {
        public static void AddSelfRegisteredExtensions(this global::Microsoft.Testing.Platform.Builder.ITestApplicationBuilder builder, string[] args)
        {
            global::Microsoft.Testing.Platform.MSBuild.TestingPlatformBuilderHook.AddExtensions(builder, args);
        }
    }
}

Note the namespace System.Security.Cryptography.ProtectedData.Tests -- this namespace doesn't appear anywhere in the project, it's synthesized from the project name. This is generally a bad idea. The problem is this:

1. System.Security.Cryptography.ProtectedData.Tests references System.Security.Cryptography.ProtectedData.
2. System.Security.Cryptography.ProtectedData doesn't define that namespace -- it defines System.Security.Cryptography
3. S.S.C.ProtectedData contains a public type named ProtectedData.
4. Usage of ProtectedData in S.S.C.ProtectedData.Tests now generates errors because there's an unresolvable ambiguity between the generated namespace (System.Security.Cryptography.ProtectedData) and the type (System.Security.Cryptography.ProtectedData).

Working around this requires extern aliases, which is a fairly uncommon feature and tricky to use.

My recommendation here would be to never synthesize new namespace names. If you're generating code for a particular type, you could consider putting more code inside that type's namespace. You could also use a namespace of your own, e.g. Microsoft.Testing.Platform. You could even put things in the global namespace. But synthesizing new namespaces is a recipe for tricky conflicts.

[bradwilson]

If memory serves, the motivation for using the RootNamespace was to prevent conflicts from one test project referencing another test project, and causing compiler conflicts (since both would have a SelfRegisteredExtensions in the same fixed namespace).

Obviously, if the algorithm for what namespace this type lives in changes, it will be a breaking change to anything which currently depends on locating it (like xUnit.net v3's default entry point for test projects).

(Also, I'm guessing this issue probably needs to live in https://github.com/microsoft/testfx, but someone from the TestFx team can move it with GitHub.)

[agocke]

A middle ground might be using a unique root at the start. Something like MTP.{RootNamespace} etc

[nohwnd]

Moved here, this is where mtp lives. IIRC @Youssef1313 was against using root or custom prefixes.

[Youssef1313]

We had some internal discussions with other teams and we decided that RootNamespace is the right thing to use. Plus it's already used by some source generators. We didn't think we are special here. You can change RootNamespace for your test project by adding <RootNamespace></RootNamespace> in a property group. I don't think we will want to change this behavior, esp that it will be a non-negligible breaking change.

[Youssef1313]

My recommendation here would be to never synthesize new namespace names. If you're generating code for a particular type, you could consider putting more code inside that type's namespace. You could also use a namespace of your own, e.g. Microsoft.Testing.Platform. You could even put things in the global namespace. But synthesizing new namespaces is a recipe for tricky conflicts.

This was problematic for other situations, where users tend to have test projects referencing each other, and generating in the same namespace creates ambiguity.

[Youssef1313]

If very absolutely necessary, what we might consider here is introducing a property to force using global namespace.

[bradwilson]

Doesn't EmbeddedAttribute solve this problem? https://github.com/dotnet/roslyn/blob/main/docs/features/incremental-generators.cookbook.md#put-microsoftcodeanalysisembeddedattribute-on-generated-marker-types

Edit: Never mind, that requires a minimum of .NET 9 SDK.