To open Visual Studio, Godot starts a process using the GodotTools.OpenVisualStudio.exe application. Can you check that your Godot editor has this file? It should be in the directory GodotSharp\Tools next to the Godot editor's executable.

Also, keep in mind Godot only supports Visual Studio 2022 and 2019. What version of Visual Studio do you have installed? Did you update it recently?

There may be more information about what's happening in the console. Try opening Godot in a terminal with the --verbose flag and check the output when trying to open Visual Studio.

Thanks for this answer.

About my version of Visual Studio : I have 2022. I did not update recently. Anyway Godot 4.2.2 is still able to open it successfully.

About GodotTools.OpenVisualStudio.exe: yes, this file is here.

When I launch Godot with --verbose I see

Running: "C:/path-to-godot-4.3/bin/GodotSharp/Tools\GodotTools.OpenVisualStudio.exe" "C:/path-to-godot-project/Godot-train.sln" "C:/path-to-godot-project/code/Map.cs;1;1"

When I run this command directly in a cmd it fails with error

Failed to load the dll from [C:\Program Files\dotnet\host\fxr\8.0.7\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\dotnet\host\fxr\8.0.7\hostfxr.dll failed

• Installing .NET prerequisites might help resolve this problem.

So, at this point it may seem that the issue comes from my environment. But:

• as pointed out by the error message, the file C:\Program Files\dotnet\host\fxr\8.0.7\hostfxr.dll does exist on my file system.
• when I try with Godot 4.2.2 I see that it tries running a similar command, namely

"C:/path-to-godot4.2.2/GodotSharp/Tools\GodotTools.OpenVisualStudio.exe" "C:/path-to-project/Godot-train.sln" "C:/path-to-project/code/Map.cs;1;1"

(so, same command line but with the path to godot4.2.2) ; and when I run that command from a cmd it succeeds

Also facing the same issue. just overall weird behavior as well within visual studio when I manually open it.
For instance I get way more references to my functions and properties than actually exist within the CodeLens References

The error 0x800700C1 basically means architecture mismatch. The OpenVisualStudio application is a 32-bit executable, but it's trying to load the hostfxr DLL from a 64-bit .NET SDK. Do you have a 32-bit .NET SDK? You can check with the dotnet --info command.

We should probably build the OpenVisualStudio application for the same architecture of the Godot editor build that it's distributed with. @paulloz was right.

If I'm not mistaken, I have 64-bit .Net Sdk.

Here is the output of dotnet --info:

.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.34944930

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.100\

.NET workloads installed:
 Workload version: 8.0.100-manifests.34944930
 [aspire]
   Installation Source: VS 17.10.35122.118
   Manifest Version:    8.0.0/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.0\WorkloadManifest.json
   Install Type:        FileBased


Host:
  Version:      8.0.7
  Architecture: x64
  Commit:       2aade6beb0

.NET SDKs installed:
  2.1.818 [C:\Program Files\dotnet\sdk]
  3.1.300 [C:\Program Files\dotnet\sdk]
  5.0.403 [C:\Program Files\dotnet\sdk]
  6.0.419 [C:\Program Files\dotnet\sdk]
  8.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.27 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  DOTNET_ROOT       [C:/Program Files/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Yes, you have a 64-bit .NET SDK and also 32-bit. But you also have the DOTNET_ROOT environment variable pointing to the 64-bit installation which is probably why it's picking up the wrong hostfxr. You should be able to remove the DOTNET_ROOT environment variable, since your .NET SDK is installed in a standard location.

Thanks for the explanation!
Indeed, launching Godot with DOTNET_ROOT='' ./Godot_v4.3-stable_mono_win64.exe fixes this issue.

There is still one thing that I don't understand: Why don't I have the same issue with Godot 4.2.2?
I just checked (using this approach), and its GodotTools.OpenVisualStudio.exe was already 32 bits; yet with Godot 4.2.2 (and on the same laptop and by letting DOTNET_TOOL set to my 64-bit installation) it succeeds in opening VS.

Other question: if I build Godot on my laptop, how can I get a 64 bits version of GodotTools.OpenVisualStudio.exe?
Currently I build with scons platform=windows module_mono_enabled=yes and I just check and it gives me a 32 bits GodotTools.OpenVisualStudio.exe. I've also skimmed through the options available in SConstruct file (and looked at modules/mono/SCsub) but couldn't find anything.

Why don't I have the same issue with Godot 4.2.2?

Because in 4.2.2 GodoTools.OpenVisualStudio.exe was built using .NET Framework. For 4.3 we switched to .NET Core.

• C#: Upgrade TFM for net472 and some netstandard2.0 projects #86454

if I build Godot on my laptop, how can I get a 64 bits version of GodotTools.OpenVisualStudio.exe?

It's hardcoded to win-x86 in the csproj:

You can manually change it to win-x64.

Should we make sure to always match the architecture, then?

Yes, I think that'd be the safest option. But since we build the official release from a Linux container we can't rely on the runtime identifier auto-detected from the .NET SDK used to build the assembly. We may have to change build_assemblies.py to allow specifying the runtime identifier, and then update the godot-build-scripts to pass the correct RID.