.NET Install Tool doesn't download a valid .NET SDK version for modern Unity .slnx files

[meckzqz]

Type: Bug

Unity's com.unity.ide.visualstudio v2.0.24+ requires .NET SDK version 9.0.200 or higher to support .slnx files, and .NET Install Tool currently downloads 9.0.10 instead. Without this issue fixed, modern Unity projects will not work in Visual Studio Code without manual intervention.

Extension version: 1.1.3
VS Code version: Code 1.106.0 (ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57, 2025-11-11T16:02:25.943Z)
OS version: Linux x64 6.17.8-arch1-1
Modes:

[jbevain]

@meckzqz thank you for reporting this!

[sailro]

Interesting issue.

So, in the Unity extension we use the .NET Install Tool as well, because we have assemblies to execute, with a rule >= 9.0 (no level band), but only for the runtime. We do not express any requirements regarding an SDK for now.

I believe this is probably more on the C# DevKit side. Indeed we have slnx files for Unity projects, so .NET SDK 9.0.200 is required.

@meckzqz could you confirm the C# DevKit version you are currently using ? Is it up-to-date ? Does using the pre-release version fixing the issue ?

Adding @lifengl and @harleend to the thread, because from the git blame on C# DevKit, I can see that you updated both NET_SDK_VERSION_SUPPORTING_SLNX and NET_SDK_SUPPORTED_PREVIEW_RUNTIME_MIN_VERSION to 9.0.200.

From what I understand, the stable version of C# DevKit does not have strict requirements for the .NET SDK (version 6.0 seems to be sufficient), and will conditionally support slnx if the SDK is >= 9.0.200.

Wouldn't it be better to initiate the acquisition of a compatible SDK in this case instead of returning an error?

Adding @nagilson to the thread as well.

[meckzqz]

Thanks for the quick responses!

@sailro, I've tested both C# Dev Kit 1.80 Release and 1.81 Prerelease, neither of which fix this issue unfortunately. Fair enough if this issue is more concerned with C# Dev Kit at the end of the day.

For what it's worth, I did notice in the changelog for .NET Install Tool 3.0.0 (unreleased) that a setting is being added to specify a local .NET SDK, which would be much appreciated. Unless I'm mistaken, because the Unity extension has both C# Dev Kit and .NET Install Tool as dependencies, there isn't a way at this point in time to get things working without .NET Install Tool recognizing a valid .NET installation. On Windows and macOS I'm able to get things up and running manually, though on Linux the extension seems to fail finding the architecture of the dotnet host, even with a PATH that contains an installation with a matching architecture. This may be a different problem entirely, but I thought it'd be worth bringing up. At this point in time, Unity development on Linux with Visual Studio Code seems thoroughly busted for now.

[sailro]

C# extension is also using the .NET Install Tool to acquire the 9.0.1 runtime (for the LSP):

https://github.com/dotnet/vscode-csharp/blob/3d1c89afbfcb0a1ba54d46cb4590cfc2381e85b2/src/lsptoolshost/dotnetRuntime/dotnetRuntimeExtensionResolver.ts#L24-L26

[sailro]

@meckzqz indeed I was able to reproduce the issue using a ubuntu box.

While waiting to find a solution, I managed to get it working manually by doing the following:

1- Moved NET Install Tool, C# and C# Dev Kit extensions to pre-release versions.

2- Manually installing a compatible SDK:

I'm using ubuntu 24, and the only SDK available on the apt repository is 9.0.112 so I used the manual installation script like this:

wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh
chmod +x ./dotnet-install.sh
./dotnet-install.sh --channel 9.0.2xx

So now I have a 9.0.205 SDK in ~/.dotnet :

~/.dotnet/dotnet --list-sdks
9.0.205 [/home/debug/.dotnet/sdk]

3- Setup extensions to use this SDK

In VSCode, use File/Preferences/Settings, then go to Extensions/.NET Install Tool. For the Dotnet Acquisition Extension: Existing Dotnet Path click on Edit in settings.json.

I'm using this configuration:

{
    "dotnetAcquisitionExtension.allowInvalidPaths": true,
    "dotnetAcquisitionExtension.existingDotnetPath": [
         {
            "extensionId": "ms-dotnettools.csharp",
            "path": "~/.dotnet/dotnet"
        },
        {
            "extensionId": "ms-dotnettools.csdevkit",
            "path": "~/.dotnet/dotnet"
        }
    ]
}

And we can see that C# Dev Kit is now using the proper SDK:

2025-11-18 13:02:06.466 [info] Starting opening a solution...
2025-11-18 13:02:06.467 [info] Starting collecting .csproj files in the workspace in Dev Kit Server...
2025-11-18 13:02:06.489 [info] Starting Spawn .NET server...
2025-11-18 13:02:06.490 [info] Using dotnet resolution provided by ".NET Install Tool".
2025-11-18 13:02:06.985 [info] Using existing .NET runtime at "~/.dotnet/dotnet" to load Dev Kit processes.
2025-11-18 13:02:07.125 [info] .NET Sdk found: "/home/debug/.dotnet/dotnet".
2025-11-18 13:02:07.382 [info] Workspace folder: /home/debug/Minimal2022, requires SDK version: 9.0.205
2025-11-18 13:02:07.389 [info] Asp.Net runtime found, using Asp.Net runtimeconfig for project system host.
2025-11-18 13:02:08.725 [info] .NET server started and IPC established in 1335ms
2025-11-18 13:02:08.736 [info] Completed Spawn .NET server (2256ms)
2025-11-18 13:02:09.548 [info] Completed collecting .csproj files in the workspace in Dev Kit Server (3085ms)
2025-11-18 13:02:09.598 [info] Starting restoring NuGet packages...
2025-11-18 13:02:09.599 [info] Selected configuration: <Default>, active configuration: Debug|Any CPU
2025-11-18 13:02:09.599 [info] Completed opening a solution (3136ms)

[meckzqz]

Thanks for another update @sailro. I had gone down this exact path myself as a temporary solve but hadn't used the pre-release versions of the extensions, so I wiped all my existing dotnet data and followed your steps exactly to give it another shot. Unfortunately, no dice over here on Arch with kernel 6.17.8. Here's the result of C# Dev Kit attempting to load things up:

2025-11-18 04:20:19.707 [info] Starting opening a solution...
2025-11-18 04:20:19.707 [info] Starting collecting .csproj files in the workspace in Dev Kit Server...
2025-11-18 04:20:19.710 [info] Starting Spawn .NET server...
2025-11-18 04:20:19.711 [info] Using dotnet resolution provided by ".NET Install Tool".
2025-11-18 04:20:20.054 [info] Using existing .NET runtime at "~/.dotnet/dotnet" to load Dev Kit processes.
2025-11-18 04:20:20.813 [info] Could not find installed SDK.
2025-11-18 04:20:20.814 [info] Asp.Net runtime found, using Asp.Net runtimeconfig for project system host.
2025-11-18 04:20:20.822 [info] .NET server STDERR: You must install .NET to run this application.

App: /home/debug/.vscode/extensions/ms-dotnettools.csdevkit-1.81.7-linux-x64/components/vs-green-server/platforms/linux-x64/node_modules/@microsoft/visualstudio-server.linux-x64/Microsoft.VisualStudio.Code.Server
Architecture: x64
App host version: 9.0.10
.NET location: Not found

Learn more:
https://aka.ms/dotnet/app-launch-failed

Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=linux-x64&os=arch&apphost_version=9.0.10
Failed to resolve libhostfxr.so [not found]. Error code: 0x80008083

2025-11-18 04:20:20.823 [info] .NET server exited with 131 

This is of course with valid paths configured in settings.json, along with the expected dotnet output of:

~/.dotnet/dotnet --list-sdks
9.0.205 [/home/debug/.dotnet/sdk]

Glad to hear things are working on your end though, perhaps I'm just doing something incorrect over here. Here's hoping for a proper solution soon!

[zach123b]

I had a similar issue using unity 6.3 in linux mint cinnamon. I would get 'ms-dotnettools.csharp: Trying to install .NET 9.0.11x64aspnetcore but it already exists. No downloads or changes were made.' and 'visualstudiotoolsforunity.vstuc: Trying to install .NET 9.0.11~x64 but it already exists. No downloads or changes were made.' on startup from opening a script in unity. I also would get a notification toast saying to ensure that my .net sdk version is 9.0.200 or higher from c# dev kit. Not sure where the installer is downloading and putting 9 but I'm not that adept in linux. I had also ran a script earlier from microsoft to install dotnet 9 and 10 which ran without error but not fixing the issue.

But, I just got it working again by putting some 9.0.307 binaries, from microsoft, in /usr/lib/dotnet which it only had 8.0 oddly. And dotnet --version only showed 8 prior to manually placing the 9 binaries in file which it states 9 now. I didn't modify any paths though

[sailro]

Yes it seems that for now the best workaround is probably to use dotnet-install.sh script to manually download a compatible SDK, and move it to /usr/lib/dotnet. I'm afraid that path overrides with the acquisition extension don't cover all cases.

[sailro]

On dotnet/sdk: dotnet/sdk#49051, and as I experimented earlier, even when registering the PPA/backports repository. The only listed version is 9.0.1xx.

Even if we (the Unity extension), force a requirement toward a 9.0.2xx SDK, the .NET Install Tool is failing on Linux stating the version is invalid. But it works as expected on windows.

[MichalPetryka]

On dotnet/sdk: dotnet/sdk#49051, and as I experimented earlier, even when registering the PPA/backports repository. The only listed version is 9.0.1xx.

Even if we (the Unity extension), force a requirement toward a 9.0.2xx SDK, the .NET Install Tool is failing on Linux stating the version is invalid. But it works as expected on windows.

Why not make it install the .NET 10 SDK instead?

[RayznGames]

I have been having this issue for quite a while. And its little frustrating. This is in Ubuntu

.NET 10 and 9.0.2 are not directly available in many Linux distributions (Ubuntu).
.NET 10 and .NET 9.0.2 both Support SLNX format.

However .NET 9.0.x / the version installed by C# Dev Kit using the .NET Installer is not a version that supports .SLNX solution formats.

Mentonable is that in the unity Package manager in older Editor Releases you can roll back the version of Visual Studio Editor
package to an older version that opens solutions using the old SLN solution format.
That totally fixes the issue with Intellisense and project since we are not longer expecting a version of the .NET SDK that may not exist for our distribution. to open a format that our .NET SDK cannot open.

However this is not true for newer Unity editor versions 6.2+ who are stuck to the 2.0.25 version of the Visual Studio package in unity and always will try to open SLNX solutions

So i believe that if unity allowed to roll back the Visual Studio Editor extension version in all UnityEditor versions to be able to open our projects with .SLN solutions just like we did until now great part of the problems would be extinguished

Maybe for Unity it would be great to only force the extension update to (2.0.25) once enough time has passed and all distributions are able to open with the new SLNX format because they finally have by default an up to date SDK that supports it.

I believe this is just an oversight in this new change to the .SLNX solutions.

I rolled back to an older editor version (6000.2.6f2) and rolled back to the older Unity VSEditor extension Package to be able to work in my projects normally.

Wish everyone the best!

[sailro]

So I ended up making this workaround script for my own usage, working perfectly on a fresh Ubuntu 24 LTS.

https://gist.github.com/sailro/726c8d98c2e0f92a1df21051b89e636b

Run it from your home folder.

[RayznGames]

Hi thanks for your time and effort!

Running the workaround as of today correctly installed the .NET 9.0.205
Fixing the issue entirely

dotnet-install: Installation finished successfully.
8.0.121 [/usr/lib/dotnet/sdk]
9.0.112 [/usr/lib/dotnet/sdk]
9.0.205 [/usr/lib/dotnet/sdk]

VSCode correctly loads SLNX solution formats with Unity and provides Intellisense

Tested in: Ubuntu 24.04.2 LTS

Unity 6000.2.6f2
Unity Visual Studio Editor Package Version: - 2.0.25

VSCode Version: - 1.106.1
C# Dev Kit Version: - 1.80.7
C# Version: - 2.100.11

Thank you, and wish everyone a wonderful day