[Dotnet] Project build hangs only on Linux (Nobara 42) --> Disable IPV6 on build

[ForeverExe]

Tested versions

Reproducible in:
Godot 4.x.x .NET

System information

Godot v4.3.stable.mono - Nobara Linux 42 (KDE Plasma Desktop Edition) - Wayland - Vulkan (Forward+)

Issue description

When building a Godot Project, the editor hangs and a dotnet process is created and runs endlessly, forcing me to kill it.

The window "Building .Net Project" stays at 0% even after 2 hours, while the window, if minimized, disappears and only the top tray remains.

When trying to compile the project manually using the command that appears in the output section, the following appears:

/usr/bin/dotnet build "/home/foreverexe/Documents/GodotProject/NewGameProject/New Game Project.csproj" -c Debug -v detailed -noconlog -l:GodotTools.BuildLogger.GodotBuildLogger,/home/foreverexe/Desktop/Godot_v4.4.1-mono/GodotSharp/Tools/GodotTools.BuildLogger.dll;/home/foreverexe/.local/share/godot/mono/build_logs/9d2d54e4e867286ebcc7a7be402f013f_Debug -p:GodotTargetPlatform=linuxbsd

MSBuild version 17.8.27+3ab07f0cf for .NET
MSBUILD : error MSB1009: Project file does not exist.
Switch: /home/foreverexe/Documents/GodotProject/NewGameProject/New Game Project.csproj
bash: /home/foreverexe/.local/share/godot/mono/build_logs/9d2d54e4e867286ebcc7a7be402f013f_Debug: Is a directory

It has the same behaviour, either be .NET 9,8 or 7 (installed through Official Fedora repositories via dnf).
I've read to try dotnet restore --verbosity diag to try resolve the issue but that hangs too after a short period of time (Assembly loaded during Evaluation: Microsoft.Build.NuGetSdkResolver, Version=6.8.1.32767, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (location: /usr/lib64/dotnet/sdk/8.0.116/Microsoft.Build.NuGetSdkResolver.dll, MVID: 023fd0f6-3461-4826-8535-04fc00ab4fd5, AppDomain: [Default], to be precise).

On Windows C# build works fine, building under a couple of seconds.

Steps to reproduce

(Using Nobara Linux 42, Dotnet-SDK-8 downloaded using dnf and official repos, nothing else done, not even changing/adding environment variables)

• Download any Godot4-Mono version
• Create a new project
• Create a C# Script and write some code
• Build the project or press Play

Minimal reproduction project (MRP)

N/A

[AThousandShips]

Does this happen in 4.4.1 as well? Would be good to get some idea if this is still relevant

[raulsntos]

I'm unable to reproduce this issue, but if the problem is the dotnet command then either we're passing the arguments wrong or it's a bug upstream.

The error MSB1009 says it can't find the .csproj file, check if this file exists. Make sure the path matches the one passed to the dotnet command exactly.

If you are still unable to fix the issue, please upload a minimal reproduction project to make it easier to troubleshoot. Make sure to include the .csproj and .sln files.

[ForeverExe]

@AThousandShips yes, it happens in 4.4.1 as well.

@raulsntos Assuming the command is the one I've mentioned in the first message, the c# project file exists and the directory is correct.

To be sure, I've made another one without spaces inside the name but it's having the same issue.
In the meantime, I've tested the build command without the logging into a file and it executes, but hangs just after launching dotnet, I cant even use Ctrl+C, I have to send a SIGKILL to stop it.
/usr/bin/dotnet build /home/foreverexe/godottest/GodotTest.csproj -c Debug -v detailed (You'll notice I've launched the command outsite the project folder when you'll read the log, inside it has the same outcome)

I repeat, I've installed dotnet 8 using Fedora Repositories, it installs dotnet inside /usr/lib64/dotnet so it could be a permission error underneath but then it would have sent me a privilege error.

I'll load a Zip with both the c# project and the log that the terminal is giving me.
Thanks in advance.

GodotMRP.zip

[raulsntos]

I still can't reproduce with the MRP and I don't see anything weird with the project. You do have an error in DirectionalLight3d.cs (the method rotate should be Rotate) but that wouldn't cause the build to hang.

It sounds a lot like it may be a bug upstream. A quick look at issues on the .NET repositories showed me a few things you could try.

Some users reported hangs caused by permission issues. Like you said, I would also expect a privilege error in this case, but maybe the logic in the dotnet CLI that handles this has a bug. You could try a manual install or a scripted install on a user-accessible directory.

Note

As per the documentation, this kind of install is not recommended for setting up a development environment and it's only meant for CI scenarios. The recommendation for Linux users is to install the .NET SDK using their distro's package manager (or, if not available, the Microsoft package repository). However, this will allow us to test if it's a permission issue.

Both the manual install and the scripted install are downloading the .NET SDK in a .tar.gz compressed archive. The only difference is the script will auto-detect what to download based on your system and extract it (by default in $HOME/.dotnet), whereas in the manual install you have to select the right one. In both cases, you still need to set the environment variables DOTNET_ROOT and PATH.

Before executing the dotnet CLI command, make sure to set the environment variable DOTNET_ROOT to the directory where you extracted the .NET SDK (should be $HOME/.dotnet if you used the default install directory with the scripted install).

Then, add the DOTNET_ROOT directory to the environment variable PATH before any other directory that contains the dotnet CLI binary so it takes precedence, or use the full path when running the dotnet CLI command.

Here's an example script that does everything and then runs the dotnet CLI command to build the Godot project (according to the path in the MRP):

#!/bin/bash

# Use dotnet-install script to install the latest .NET SDK.
curl -L https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
chmod +x ./dotnet-install.sh
./dotnet-install.sh --version latest

# Set environment variables.
export DOTNET_ROOT=$HOME/.dotnet
export PATH=$DOTNET_ROOT:$PATH

# Build the Godot project.
dotnet build /home/foreverexe/godottest/GodotTest.csproj -c Debug -v detailed

Modify the script if needed. Feel free to delete the $HOME/.dotnet directory afterwards. You can also specify a different install directory with --install-dir (see dotnet-install documentation).

If that doesn't work, it may not be a permission issue. You can also try disabling other parts of the build logic that may be causing the hang:

• Set the environment variable DOTNET_CLI_DISABLE_PROJECT_EVAL to true before running the dotnet CLI command. If that works, then the hang is in the project evaluation logic.
• Set the flag --no-restore in the dotnet CLI command. If that works, then the hang is likely in the NuGet restore logic.
• Some users also reported getting hangs with MSBuild node reuse, so you could try setting the environment variable MSBUILDDISABLENODEREUSE to 1 and see if that helps.

Let me know if any of this helped.

[ForeverExe]

@raulsntos thanks again for the help you're giving me, here's what happened:

0>Process = "/home/foreverexe/.dotnet/dotnet"
       MSBuild executable path = "/home/foreverexe/.dotnet/sdk/8.0.411/MSBuild.dll"
       Command line arguments = "/home/foreverexe/.dotnet/sdk/8.0.411/MSBuild.dll -maxcpucount -verbosity:m -nologo -restore -consoleloggerparameters:Summary -property:Configuration=Debug -verbosity:detailed /home/foreverexe/godottest/GodotTest.csproj -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/home/foreverexe/.dotnet/sdk/8.0.411/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/home/foreverexe/.dotnet/sdk/8.0.411/dotnet.dll"
       Current directory = "/home/foreverexe"
       MSBuild version = "17.11.31+933b72e36"

This is the new execution after uninstalling dotnet via package manager, and installing via script.

For all the combinations of commands you suggested me, this error appears after 11 minutes of wait:

Assembly loaded during Evaluation: System.Net.Quic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (location: /home/foreverexe/.dotnet/shared/Microsoft.NETCore.App/8.0.17/System.Net.Quic.dll, MVID: 04fa7d33-2a86-45f4-8e3e-490a0c3a6458, AssemblyLoadContext: Default)
       Resolving conflicts for .NETStandard,Version=v0.0...
       The "NuGetSdkResolver" resolver attempted to resolve the SDK "Godot.NET.Sdk/4.4.1".
       Warnings: Unable to load the service index for source https://api.nuget.org/v3/index.json.
       Errors: Unable to find package Godot.NET.Sdk. No packages exist with this id in source(s): nuget.org
     0>/home/foreverexe/godottest/GodotTest.csproj : error : Could not resolve SDK "Godot.NET.Sdk". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
/home/foreverexe/godottest/GodotTest.csproj : error :   SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" returned null.
/home/foreverexe/godottest/GodotTest.csproj : error :   Unable to find package Godot.NET.Sdk. No packages exist with this id in source(s): nuget.org
     0>/home/foreverexe/godottest/GodotTest.csproj : warning : Unable to load the service index for source https://api.nuget.org/v3/index.json.
     1>Project "/home/foreverexe/godottest/GodotTest.csproj" on node 1 (Restore target(s)).
     1>/home/foreverexe/godottest/GodotTest.csproj : error MSB4236: The SDK 'Godot.NET.Sdk/4.4.1' specified could not be found.
     1>Done Building Project "/home/foreverexe/godottest/GodotTest.csproj" (Restore target(s)) -- FAILED.

Build FAILED.

         /home/foreverexe/godottest/GodotTest.csproj : warning : Unable to load the service index for source https://api.nuget.org/v3/index.json.


         /home/foreverexe/godottest/GodotTest.csproj : error : Could not resolve SDK "Godot.NET.Sdk". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
       /home/foreverexe/godottest/GodotTest.csproj : error :   SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" returned null.
       /home/foreverexe/godottest/GodotTest.csproj : error :   Unable to find package Godot.NET.Sdk. No packages exist with this id in source(s): nuget.org


       "/home/foreverexe/godottest/GodotTest.csproj" (Restore target) (1) ->
         /home/foreverexe/godottest/GodotTest.csproj : error MSB4236: The SDK 'Godot.NET.Sdk/4.4.1' specified could not be found.

    1 Warning(s)
    2 Error(s)

It seems that it cannot find the NuGet package, if I'm correct. For me, it's always on the Desktop since for comfort I extract the Godot executable + the GodotSharp folder and place it there to access the editor immediately.

[raulsntos]

Packages are downloaded from the available NuGet source feeds unless they are already available in your NuGet packages directory. By default, the only source feed available will be nuget.org, and the packages directory is $HOME/.nuget/packages in Linux.

Judging from your error message, it looks like you may not be able to access nuget.org so it can't retrieve the packages.

It seems that it cannot find the NuGet package, if I'm correct. For me, it's always on the Desktop since for comfort I extract the Godot executable + the GodotSharp folder and place it there to access the editor immediately.

The GodotSharp directory included in the compressed archive needs to be next to the Godot editor executable because it will load some of those DLLs directly for editor integration.

However, the Godot.NET.Sdk, GodotSharp, and GodotSharpEditor packages used by the C# project are different. These are retrieved using the normal .NET restore process which doesn't know anything about the GodotSharp directory, instead it will use your configured NuGet source feeds (by default nuget.org) to retrieve them. You could technically create a custom source feed and add the packages there or install them to your packages directory, but I wouldn't recommend it.

Are you able to restore NuGet packages in other non-Godot C# projects? The error you are getting doesn't seem specific to Godot.

[ForeverExe]

• GodotSharp is next to the Godot Editor, in fact the only thing I do is extract the zip and then access the editor from inside the folder.

• I'm not able to restore non-Godot C# projects. Since you don't recommend it, I won't try to make a custom source feed.

I've mainly used C# for Godot, so I don't have a non-godot C# project at hand, so I've made a new one of the mstest type, after 10 minutes, this appears:

$ dotnet new mstest
The template "MSTest Test Project" was created successfully.

Processing post-creation actions...
Restoring /home/foreverexe/Desktop/dev/dev.csproj:
  Determining projects to restore...
/home/foreverexe/Desktop/dev/dev.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.
  Failed to restore /home/foreverexe/Desktop/dev/dev.csproj (in 10.1 min).
Restore failed.
Post action failed.
Manual instructions: Run 'dotnet restore'  **(Returns the same error)**

Checking the link, it gives a JSON which says "Resource does not exist."
I've read there should be a NuGet Config somewhere inside the project or in the user config with the correct info but I'm afraid to worsen things by changing the contents of $HOME/.nuget/NuGet/NuGet.config, so I prefer to wait.

[raulsntos]

It looks like your computer is unable to access nuget.org. Are you perhaps behind a proxy or VPN that could be causing issues?

I don't think there is an issue with your NuGet configuration, but it should be fine to remove the $HOME/.nuget/NuGet/NuGet.config file, it will be recreated by NuGet on the next restore. You may want to back it up if you have custom configuration that you may want to keep. For reference, this is how the default looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

You may also add custom NuGet configuration that only affects a specific C# project by creating a NuGet.config file next to the .csproj file.

But it sounds more like a network issue to me. There are a number of issues in the https://github.com/NuGet/Home repo that sound similar to what you are describing.

From reading some of those issues, it looks like trying to add a package may offer more information. For example: dotnet add package Newtonsoft.Json. Some users were getting an error on formating the Linux system information, but it appears that bug was fixed a while ago.