Closed gturri closed 1 month ago
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:
C:\Program Files\dotnet\host\fxr\8.0.7\hostfxr.dll
does exist on my file system."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.
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.
Tested versions
System information
Windows 11
Issue description
I have a C# script attached to a node. When I click on this icon while using Godot 4.2.2, it opens this file in Visual Studio. That's the expected behavior. When I click on this icon while using "Godot 4.3 with mono support", it does not open Visual Studio (it does not have any visible impact AFACS, in particular: I don't even see any error message). That's the actual behavior
Nb1: I have the
Èxternal Editor
for dotnet configured toVisual Studio
.Nb2: It seems an issue specific to C# (or perhaps Visual Studio) because when I use gdscript and configure an external editor (tested with VsCode), then clicking on the script icon leads to correctly opening VsCode
Steps to reproduce
Editor settings
the keyDotnet > Editor > External Editor
toVisual Studio
Minimal reproduction project (MRP)
MRP-CannotOpenVsInGodot4_3.zip