[solved] Can't create new VB form-based projects in VS2022/26.

Question

[solved] Can't create new VB form-based projects in VS2022/26.

Mugsy's RapSheet 241

I "suddenly" can't create (or even open most) VB Forms projects. I tried both VS2022 & 2026. Both tell me I need to update .Net, but doing so didn't help.

I even tried uninstalling/reinstalling the ".Net Desktop Environment" from the VS2026 Installer. No change.

About half of my existing projects open just fine. But I can't create any NEW VB Forms projects and have no idea why.

Even VS2022 can't create a new VB Forms project (both '22 & '26 CAN create Forms in C#.)

Any idea what's going on & how to fix this?

DonNet error Install DotNet6,0,36

TIA.

0 comments

Answer accepted by question author

AgaveJoe 31,706

Visual Studio's out-of-process Windows Forms designer relies on the 64-bit .NET Desktop Runtime to render the design surface.

Check installed runtimes

Open a Command Prompt and run:

dotnet --list-runtimes

Look for this entry:

Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

If this specific Microsoft.WindowsDesktop.App line is missing, or if it points to Program Files (x86) instead of Program Files, the 64-bit designer host cannot run.

Install the missing Desktop Runtime

Go to: https://dotnet.microsoft.com/en-us/download/dotnet/6.0
Under the .NET Desktop Runtime 6.0.36 section, specifically download and install the x64 installer (not x86 or the basic .NET Runtime).
Restart Visual Studio.

Note: If you install it and the error persists, run

where dotnet

in Command Prompt to make sure C:\Program Files\dotnet\dotnet.exe appears above the Program Files (x86) path in your system PATH variable.

Mugsy's RapSheet 241 Reputation points

2026-08-15T22:50:21.4033333+00:00

Thx for the reply. But I've already uninstalled/reinstalled both .Net 6.0.0 & 6.0.36 multiple times.

No difference. I've even completely uninstalled/reinstalled VS2026. No change.

The .Net check returns an error.

The "hostxfer.dll" files are exactly where the errors says they aren't.
AgaveJoe 31,706 Reputation points

2026-08-16T11:38:19.12+00:00
You did not mention the "X" drive!

If hostfxr.dll is physically present in that folder on X:, the 0x80008083 (hostfxr.dll not found) error indicates that Windows or the .NET host is failing to resolve or load binaries from the non-standard drive location.

Try the following:

Set the DOTNET_ROOT Environment Variable

Because .NET is installed on a non-default drive (X:), tools and background processes (including Visual Studio's designer) will fail to locate the host unless told where to look:

Press Win + R, type sysdm.cpl, and press Enter.

Go to the Advanced tab and click Environment Variables.

Look for DOTNET_ROOT in System variables.

If DOTNET_ROOT does not exist, create it.

Variable name: DOTNET_ROOT

Variable value: X:\Program Files\dotnet (adjust path to match your root dotnet folder on X)

Click OK, then restart Command Prompt and Visual Studio.

Network Drive Caveat (If X:\ is a mapped drive)

If X:\ is a mapped network share (UNC path / NAS), Windows security policies will actively block dotnet.exe from executing native runtime binaries (hostfxr.dll) over a network connection:

The .NET SDK and Runtimes must be installed on a local physical drive (ideally C:\Program Files\dotnet).

You can keep your solution files and source code on X:, but the core .NET toolchain and Visual Studio shared SDKs should reside locally.

Recommended Fix: Install .NET to the Default C:\ Location

If setting DOTNET_ROOT does not immediately resolve the error:

Reinstall the .NET 9 / .NET 8 SDK and the .NET 6.0 Desktop Runtime (x64) to the default C:\Program Files\dotnet\ path.

In your PATH environment variable, ensure C:\Program Files\dotnet\ is present and takes precedence.

Test again with dotnet --list-runtimes. Once that command succeeds, the Visual Studio designer error will be resolved.
Mugsy's RapSheet 241 Reputation points

2026-08-16T17:40:56.4066667+00:00

Thanks for the reply. I'm not sure when or how .Net was relocated to my X: drive.

"DOTNET_ROOT" was not in my path so I added it, rebooted, did a reinstall/repair of DotNet 6, 8, 9 and 10, then tried to create a new VB Forms project.

Didn't work. Still asks me to install .Net. :(

The DotNet installers do not give you the option of setting the location. I can't verify where the installers are putting the files.

"dotnet --list-runtimes" still says their location to be on my "X:" drive.
AgaveJoe 31,706 Reputation points

2026-08-16T18:21:04.0233333+00:00
The standard .NET runtime and SDK installers will never install to an X: drive on their own—by default, they install strictly to C:\Program Files\dotnet.

If I recall, the only time Visual Studio allows you to customize that path is during its very first installation, where the "Shared components, tools, and SDKs" location can be set to another drive. Once set, that location is locked across all future Visual Studio updates and related toolchain installs.

You can verify where Visual Studio has registered its shared tools by running this command in PowerShell:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\VisualStudio\Setup" -Name "SharedInstallationPath" -ErrorAction SilentlyContinue

It is difficult to diagnose why the runtime ended up on X: remotely, but having the .NET toolchain split across different drives can lead to path resolution issues and the 0x80008083 (hostfxr.dll not found) error you are seeing.

While you could try manually fixing the PATH environment variables, DOTNET_ROOT, and registry keys, dealing with a split-drive configuration can be messy. In my opinion, the cleanest fix is to completely uninstall Visual Studio and any standalone SDKs/runtimes, delete the orphaned folders, and perform a fresh reinstall to the default C: drive.
Mugsy's RapSheet 241 Reputation points

2026-08-16T18:37:10.5533333+00:00

Knowing .Net was installing to C: but looking for X:, I checked the registry (RegEdit) and found it filled with paths to both locations.

I deleted all the DotNet reg entries pointing to X:, set the Dontnet root path back to C:, rebooted, reinstalled DotNet 6/8/9/10, and everything appears to be working now.

Big thanks. This was driving nuts.

1 additional answer

Your answer

Mugsy's RapSheet 241 Reputation points

2026-08-15T22:50:21.4033333+00:00

Thx for the reply. But I've already uninstalled/reinstalled both .Net 6.0.0 & 6.0.36 multiple times.

No difference. I've even completely uninstalled/reinstalled VS2026. No change.

The .Net check returns an error.

The "hostxfer.dll" files are exactly where the errors says they aren't.
AgaveJoe 31,706 Reputation points

2026-08-16T11:38:19.12+00:00

You did not mention the "X" drive!

If hostfxr.dll is physically present in that folder on X:, the 0x80008083 (hostfxr.dll not found) error indicates that Windows or the .NET host is failing to resolve or load binaries from the non-standard drive location.

Try the following:

Set the DOTNET_ROOT Environment Variable

Because .NET is installed on a non-default drive (X:), tools and background processes (including Visual Studio's designer) will fail to locate the host unless told where to look:

Press Win + R, type sysdm.cpl, and press Enter.

Go to the Advanced tab and click Environment Variables.

Look for DOTNET_ROOT in System variables.

If DOTNET_ROOT does not exist, create it.

Variable name: DOTNET_ROOT

Variable value: X:\Program Files\dotnet (adjust path to match your root dotnet folder on X)

Click OK, then restart Command Prompt and Visual Studio.

Network Drive Caveat (If X:\ is a mapped drive)

If X:\ is a mapped network share (UNC path / NAS), Windows security policies will actively block dotnet.exe from executing native runtime binaries (hostfxr.dll) over a network connection:

The .NET SDK and Runtimes must be installed on a local physical drive (ideally C:\Program Files\dotnet).

You can keep your solution files and source code on X:, but the core .NET toolchain and Visual Studio shared SDKs should reside locally.

Recommended Fix: Install .NET to the Default C:\ Location

If setting DOTNET_ROOT does not immediately resolve the error:

Reinstall the .NET 9 / .NET 8 SDK and the .NET 6.0 Desktop Runtime (x64) to the default C:\Program Files\dotnet\ path.

In your PATH environment variable, ensure C:\Program Files\dotnet\ is present and takes precedence.

Test again with dotnet --list-runtimes. Once that command succeeds, the Visual Studio designer error will be resolved.
Mugsy's RapSheet 241 Reputation points

2026-08-16T17:40:56.4066667+00:00

Thanks for the reply. I'm not sure when or how .Net was relocated to my X: drive.

"DOTNET_ROOT" was not in my path so I added it, rebooted, did a reinstall/repair of DotNet 6, 8, 9 and 10, then tried to create a new VB Forms project.

Didn't work. Still asks me to install .Net. :(

The DotNet installers do not give you the option of setting the location. I can't verify where the installers are putting the files.

"dotnet --list-runtimes" still says their location to be on my "X:" drive.
AgaveJoe 31,706 Reputation points

2026-08-16T18:21:04.0233333+00:00

The standard .NET runtime and SDK installers will never install to an X: drive on their own—by default, they install strictly to C:\Program Files\dotnet.

If I recall, the only time Visual Studio allows you to customize that path is during its very first installation, where the "Shared components, tools, and SDKs" location can be set to another drive. Once set, that location is locked across all future Visual Studio updates and related toolchain installs.

You can verify where Visual Studio has registered its shared tools by running this command in PowerShell:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\VisualStudio\Setup" -Name "SharedInstallationPath" -ErrorAction SilentlyContinue

It is difficult to diagnose why the runtime ended up on X: remotely, but having the .NET toolchain split across different drives can lead to path resolution issues and the 0x80008083 (hostfxr.dll not found) error you are seeing.

While you could try manually fixing the PATH environment variables, DOTNET_ROOT, and registry keys, dealing with a split-drive configuration can be messy. In my opinion, the cleanest fix is to completely uninstall Visual Studio and any standalone SDKs/runtimes, delete the orphaned folders, and perform a fresh reinstall to the default C: drive.
Mugsy's RapSheet 241 Reputation points

2026-08-16T18:37:10.5533333+00:00

Knowing .Net was installing to C: but looking for X:, I checked the registry (RegEdit) and found it filled with paths to both locations.

I deleted all the DotNet reg entries pointing to X:, set the Dontnet root path back to C:, rebooted, reinstalled DotNet 6/8/9/10, and everything appears to be working now.

Big thanks. This was driving nuts.

Answer 1

Leon Tran (WICLOUD CORPORATION) 2,150 Microsoft External Staff Moderator

Hi @Mugsy's RapSheet ,

Thank you for sharing your solution.

Cleaning up the outdated .NET registry entries was an effective troubleshooting step in this case. A standard reinstallation may not always remove incorrect or leftover registry entries, which can continue to affect runtime detection.

However, manually modifying or deleting registry entries can cause serious system issues if the wrong entry is changed. We recommend backing up the registry before making any modifications. I’m glad that you completed the steps carefully and resolved the issue successfully.

Visual Studio allows some shared components, tools, and SDKs to be installed on another drive. However, if the custom installation location causes runtime detection or loading issues, reinstalling the affected components in the default location on the C: drive may help.

Once again, thank you for contributing your solution. If possible, please use the available options on the page to mark or rate the helpful response. This will make the solution easier to find for others experiencing a similar issue.

If you have any further questions, feel free to leave a comment.

Mugsy's RapSheet 241 Reputation points

2026-08-17T11:00:24.49+00:00

Yep, the first thing I did before making any changes was to right-click the Parent key and save it to a ".reg" file in case I broke something.

Screwing around with the Registry is definitely not something for the novice.

"AgaveJoe"s noticing my .Net files were on the wrong drive deserved to be marked as the answer but I do not have the option.)
Leon Tran (WICLOUD CORPORATION) 2,150 Reputation points Microsoft External Staff Moderator

2026-08-18T00:20:42.2266667+00:00

Hi @Mugsy's RapSheet ,

As I can see, you have marked AgaveJoe’s answer as the accepted solution to your issue. Since the problem has been resolved and you do not have any further questions, I will go ahead and close this thread.

Thank you for participating in the discussion, and I hope you have a great day!