[dotnet-sdk-8.0.100-preview.1.23107.4] Custom class "Windows" result to its elements cannot be recognized in .NET 8.0

Application Name: mRemoteNG OS: Windows10 21h2 CPU: x64 App or App Source checking at: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1744505

Verify Scenarios: 1).Windows 10 21H2 AMD64 + dotnet-sdk-8.0.100-preview.1.23107.4 + app (default 6.0): Pass 2). Windows 10 21H2 AMD64 + dotnet-sdk-8.0.100-preview.1.23107.4 + app (retarget 8.0): Fail 3). Windows 10 21H2 AMD64 + dotnet-sdk-7.0.103-win-x64 + app (retarget 7.0):Pass

Repro steps:

1. Copy app source from mRemoteNG folder.
2. Retarget the app from .NET 6.0 to .NET 8.0 by changing net6.0-windows to net8.0-windows in mRemoteNG.csproj. <TargetFramework>net8.0-windows</TargetFramework>
3. Open Developer command prompt for VS2022 and run “MSBuild mRemoteNG.csproj” Expected Result: Build successful. Actual Result: Build failed with errors:

Minimal Repro sample: Minimal repro sample attached: mRemote demo.zip

1. Create a default .net8.0 WinForm app.
2. Add a Test folder in the project and add a custom class named “Windows”. Windows.cs:

namespace WinFormsApp1.Test
{
    internal class Windows
    {
        public static void Show()
        { 
        }
    }
}

1. Add the namespace of custom Windows class and call its method in Form1.cs:

using WinFormsApp1.Test;
namespace WinFormsApp1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            //This line will show error, if we changed to use "WinFormsApp1.Test.Windows.Show();", the error will go
            Windows.Show(); 
        }
    }
}

Expected Result: Build successful.

Actual Result: Build failed with errors: Error CS0234 The type or namespace name 'Show' does not exist in the namespace 'Windows' (are you missing an assembly reference?)

Findings: Caused by the custom class named “Windows”, it seems conflicts with the Windows in .net8.0 sdk. If we change the class name, it works. If we use mRemoteNG.App.Windows directly in code instead of adding “using mRemoteNG.App;” on top of the class then use Windows in code, the errors can be fixed.

@dotnet-actwx-bot @dotnet/compat

[JeremyKuhne]

The other, I think much more palatable option, is to “Won’t Fix” this issue.

In general, I’m inclined to agree with you. This one is a little more user abusive as using Windows is expected to hit a number of folks.

If it’s due to internal namespaces that you own then consider naming them less common names.

It’s an option. I’d prefer not to as these namespaces are coming directly from the Windows published metadata assemblies. It also would require a feature add from CSWin32, which complicates things.

@AArnott heads up on this. I’m still investigating trimming our ref assemblies but might be circling around with you about the plausibility of customizing the root namespace.

[jaredpar]

Why does it even consider the internal namespace if the assembly has no access?

Because internal, even in the abscence of IVT, can impact whether a declaration is legal or not. Consider as a simple example:

// assembly1 
[IVT: assembly2]
public abstract class C1 {
  internal abstract void M(); 
}

// assembly2
pubic class C2 : C1 {
  internal override void M() { }
}

If you don’t include C2.M then the compiler has to consider that C2 is abstract. There is no member that satisfies the abstract. Therefor the compiler must export and import internal members for C2 even though assembly2 has an empty IVT list.