UseWindowsForms causes token Windows to be clobbered in global scope.
#39299
Comments
dotnet-issue-labeler
bot
added
Area-NetSDK
untriaged
|
This reproduces the same error without defining <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0-windows7.0</TargetFramework>
<LangVersion>10.0</LangVersion>
</PropertyGroup>
<ItemGroup>
<Reference Include="C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\8.0.2\ref\net8.0\System.Windows.Forms.Primitives.dll" />
</ItemGroup>
</Project>So the error is caused by System.Windows.Forms.Primitives.dll, which indeed defines many namespaces whose names start with If you don't use top-level statements, and instead define a namespace Foo
{
class Program
{
static void Main()
{
Windows.Bar();
NotWindows.Baz();
}
}
}then it will build just fine. |
|
The Microsoft.Windows.CsWin32 package could perhaps add a feature to allow renaming namespaces; then the System.Windows.Forms.Primitives project could rename the Alternatively, it might be possible to eradicate the |
|
Good catch with I don't think the use of top level statements has anything to do with it. I believe your example there dodges it because putting This using Foo;
namespace App
{
class Program
{
static void Main()
{
Windows.Bar(); // CS0234 if
NotWindows.Baz();
}
}
}All that said, I now wonder after you've pointed out that the namespace is coming from Edit to add:
This feels like the ideal path to me. I'm not sure why a reference assembly would be filled with namespaces and classes that you can't even reference! 😂 |
This was the first thing I tried: namespace Foo;
Windows.Bar();
NotWindows.Baz();but it causes error CS0116: A namespace cannot directly contain members such as fields, methods or statements. So, I don't think you can put the code into |
If Windows Forms has a public |
MiYanni
added
needs team triage
Describe the bug
In a project that is making use of
<UseWindowsForms>true</UseWindowsForms>, an attempt to access an unqualified symbol namedWindowswill causecscto produce aCS0234. If the symbol is named anything other than windows, this does not occur. Unlike other library provided namespaces (e.g.:System,) there is noWindowsnamespace in the global scope. It appears to believe thatWindowsis a namespace, regardless of the current scope'susings. I have confirmed that this behavior is unaffected by the state ofImplicitUsings. Edited to add: of note,<UseWPF>true</UseWPF>does not produce this behavior.To Reproduce
Repro 1
Create a project with the following files. The
.csfiles can be combined into a single file with appropriate namespace bracing. The result is the same either way.repro.csprojProgram.cs:Foo.cs:Repro 2
Attempt to build project, and observe emitted
CS0234:Repro 3
Modify
repro.csprojas follows:Repro 4
Build again, observing successful compilation:
Exceptions (if any)
N/A.
Further technical details
dotnet --infodotnet --info:IDE: None, but I did test that this reproduces with VS v17.8.7.
The text was updated successfully, but these errors were encountered: