Install location confusion

[siewers]

When running the script, it will install to the %LOCALAPPDATA%\Microsoft\dotnet directory by default. However, the default SDK location is %PROGRAMFILES%\dotnet. This leads to issues with IDEs and dotnet in general, as it relies on the SDKs being located under Program Files.

I might be using the script for an unintended purpose, but it's the closest thing I've come to easing the installation of the SDK specified in global.json, without the user manually having to download the version using WinGet or similar.

Is it an invalid use case to use this script to install the .NET SDK locally and is it required to use the .NET SDK installers for this purpose?

[baronfel]

These scripts are not intended to replace the global installers for the .NET SDK - they are specifically for local, not-shared installs. For best compatibility/convenience we recommend the use of the global installers for your platform. If you choose to use these scripts to manage SDK installations, it is incumbent on you to correctly configure your system to use and understand the locally-installed SDKs and runtimes.

Regarding

This leads to issues with IDEs and dotnet in general, as it relies on the SDKs being located under Program Files.

please raise issues when you see this - the IDEs and dotnet CLI should easily support using local installations when configured correctly, and if you have examples of when this is not the case then we would treat them as bugs to be fixed in the product.

[siewers]

Alright, that makes sense. It works when configured correctly, e.g., in JetBrains Rider, but since it's not the recommended approach, I'll create a script to parse the global.json file manually. For shared team projects, it would be very convenient to have a tool that" just works" and installs the .NET SDK version specified in global.json.

Would you happen to know of such a tool?

please raise issues when you see this

Where should I raise these issues?

[baronfel]

For problems with 'dotnet' itself, dotnet/SDK would be the correct repo. For VS they use developer community, and for DevKit you want the microsoft/vscode-dotnettools repo

For what it's worth, the pattern you describe I think is totally reasonable - in fact across the dotnet/ org we use dotnet/arcade to do much the same. Every repo has a build.cmd/sh script that uses these install scripts to install an SDK/Runtime to the .dotnet directory inside that repo - but it also configures PATH, DOTNET_ROOT, etc to ensure correct behavior. Then, if you launch the IDE from that shell the IDE should behave.

[siewers]

Thanks for the quick response! I'll have a look over there for something related to this.

For anyone interested, I used WinGet instead and manually parse the global.json file. The behavior is not perfect, as I don't intend to evaluate the rollForward property, but it's good enough as long as the feature version matches. Hopefully, tooling support will arrive soon.

The script itself is straightforward:

# Identify the .NET SDK version in global.json
$globalJson = Get-Content "global.json" | ConvertFrom-Json
$version = $globalJson.sdk.version

# Get the major version to identify the package to install
$majorVersion = $version.Split('.')[0]

# Construct package ID based on the major version
$packageId = "Microsoft.DotNet.SDK.$majorVersion"

# Install the .NET SDK package
Write-Host "Installing the .NET SDK version $version"

winget install --id $packageId --version $version