[NETSDKE2E][Green] The new file created by using the command .NET: New File cannot be opened automatically.

[yinjiehe01]

REGRESSION INFO
Also repro on C#DK April release build 3.20.199

INSTALL STEP
1.Install SDK 10.0.300 on Linux.
2.Install latest VS Code and C# dev kit May prerelease 3 3.21.203 (C# 2.142.16) extension.

REPRO STEPS
Click the Create .NET Project button and select console projects.
F1->.NET: New File ->Class-> Name the new file and press Enter.

Expected
The new file will be opened automatically after pressing Enter.

Actual
The new file will not be opened automatically.

[yinjiehe01]

The added file name cannot be automatically detected as duplicate, and the suggestion name doesn't auto increase, like Class1,Class2,Class3….. Always provides the name 'Class'

Expected:

Actual:

[claudiaregio]

@drewnoakes can you take a look for RCA? going to pull this into May iteration as P2

[drewnoakes]

@yinjiehe01 do you know if this is a regression?

Going to assign this to @phenning as he has been working in this area most recently. Phil, let me know if you need a second pair of eyes on anything here.

[yinjiehe01]

@drewnoakes as mentioned in bug description, it is now not a regression bug.
REGRESSION INFO
Also repro on C#DK April release build 3.20.199

[danroth27]

I'm seeing the same behavior on Windows. The new file is correctly written to disk, but the editor never focuses it; the previously-opened Program.cs remains the active tab.

Reproduces 3 / 3 times on a clean profile here, so this looks deterministic rather than racy.

Environment

• Windows 11
• VS Code 1.105.0 stable
• C# Dev Kit 3.20.199 + C# 2.140.8 + .NET runtime 3.0.2
• .NET SDK 11.0.100-preview.5

Steps (same as the original repro):

1. Fresh empty workspace.
2. .NET: New Project → Console App → Repro1 → .sln → Create.
3. Wait for Solution: Repro1.sln in the status bar.
4. .NET: New File → select project → Class template → name MyClass → Enter.

Observation

MyClass.cs is created on disk (68 bytes, valid template content). However, the extension host logs an unhandled rejection from the post-create open call:

[Extension Host] rejected promise not handled within 1 second:
CodeExpectedError: cannot open file:///c%3A/.../Repro1/MyClass.
Detail: Unable to read file '...\Repro1\MyClass'
  (Error: Unable to resolve nonexistent file '...\Repro1\MyClass')
    at CRe.$tryOpenDocument (workbench.desktop.main.js:1035:10890)

The path passed to tryOpenDocument is missing the .cs extension. The file on disk has the extension, so the disk write and the open call appear to be using different forms of the filename. Same behavior across all 3 runs (paths only differ by project name).

@phenning hopefully this saves you a step — happy to grab more logs if it'd help.

[danroth27]

Follow-up — narrowing what triggers this.

If I create the project via the CLI instead of Dev Kit, the bug does not reproduce:

dotnet new console -n Repro1
dotnet new sln -n Repro1 -f sln
dotnet sln add Repro1.csproj

Opening that workspace and running .NET: New File → Class → MyClass works correctly — the new file opens in the editor.

If I create the project via .NET: New Project instead (everything else identical: same Dev Kit build, same VS Code, same SDK, same user profile), the bug reproduces every time.

Disk-level diffs between the two workspaces (same .sln, same .csproj, same Program.cs):

	CLI-created (works)	.NET: New Project-created (broken)
Layout	.sln and .csproj in the same folder	.sln at workspace root, .csproj in Repro1/ subfolder
.vscode/settings.json	absent	present, {"dotnet.defaultSolution": "Repro1.sln"}

I haven't bisected which of those two differences is the trigger, but together they're sufficient.

One more datapoint: I can take a verbatim copy of the .NET: New Project-created workspace (delete MyClass.cs and bin/obj), open it in a fresh VS Code profile, and .NET: New File still fails — so it's the on-disk shape that matters, not anything cached in workspace storage from the original .NET: New Project run.

Hope this narrows the search for @phenning.

[phenning]

RCAed the issue, this was regressed back in April when the fallback template support was removed - the host file included in the template nupkg is what provided the primary file extension of the item in order to fully support the scenario. The default template.json does not provide this information.

I have a PR out to work around the need for the host file now.

@drewnoakes , FYI