Flexibility in SDK install folder

As a Visual Studio user, I can specify the folder for the .NET Core SDK that is different from c:\program files\dotnet so that I can reduce the footprint on the system drive.

---

Visual Studio will have flexibility in its installation location - therefore, SDK will also have flexibility in its installation location.

Scenarios Installations:

1. an SDK installation chained from a Visual Studio installation instance
2. a ‘stand-alone’ SDK installation

---

Work Items

SetUp work items [area-Setup]:

• Visual Studio installer communicates the install folder to the SDK MSI https://github.com/dotnet/cli/issues/10157
• Manage the SDK bundle installation locations https://github.com/dotnet/cli/issues/10156
• The SDK bundle installer Procedure [Windows] https://github.com/dotnet/cli/issues/10155
• SDK resolver in Visual Studio & command shell experience https://github.com/dotnet/cli/issues/10243
• Add properties to override default location for shared framework installer in Windows https://github.com/aspnet/AspNetCore/issues/3697
• The Runtime bundle installer Procedure [Windows] not needed at this time - @rakeshsinghranchi

Host work items [area-Host]:

• Runtime dynamic multilevel lookup - muxer https://github.com/dotnet/core-setup/issues/4637
• SDK muxer [the host] and multi-level lookup https://github.com/dotnet/cli/issues/10153
• ASP.NET’s native code to locate the hostfxr https://github.com/aspnet/IISIntegration/issues/1566

Documentation:

• Advertise the dynamic VS/SDK install folder change https://github.com/dotnet/cli/issues/10152

Testing:

SDK bundle ‘other-volume’ testing… To install the SDK bundle to another volume: Example: dotnet-sdk-3.0.100-alpha1-009719-win-x64.exe /install DOTNETHOME_X64="D:\dotnet\x64" DOTNETHOME_X86="D:\dotnet\x86" /log "installation.log" /quiet /norestart

[vitek-karas]

@johnbeisner might know the meaning of all the registry keys - do we have a document describing those? (if not, we definitely should).

@miloush Just curious what is the scenario you’re trying to solve:

• All this information is already available if you run dotnet --info
• Do you need this as an API - so that you can get this info without parsing the text output of dotnet --info?
• What is the scenario where you need to know all the installed versions of SDKs?
• What is the scenario where you need to know all the installed runtimes?
• What about the other frameworks - runtime is in the Microsoft.NETCore.App, but there are other shared frameworks (ASP.NET, with .NET Core 3 there will be the WinForms/WPF one as well)

With the proposed changes by this issue these should work:

• Host lives in the location specified by the HKLM\Software\dotnet\Setup\InstalledVersions\x64\InstallLocation (this is a new key) - there you should find the dotnet.exe - you can look at its version if you need to, but I would be very curious what is the scenario for that.
• hostfxr - lives next to the host (See above) in the host/fxr subdirectory - the rule is to always use the latest available version (the older versions are effectively ignored)
• Frameworks should also live next to the host in the shared subdirectory. I don’t know about the .version file, the host doesn’t use that. The host solely relies on the directory names to recognize the versions.

[miloush]

I see, thank you. So as per your response to dotnet/cli#4904, I can get:

• Host version from the registry (there is only one host)
• Installed SDK versions by interop call to hostfxr_get_available_sdks in hardcoded %ProgramFiles%\dotnet\host\fxr\*\hostfxr.dll libraries.
• Available runtime versions by checking hardcoded %ProgramFiles%\dotnet\shared\Microsoft.NETCore.App\*\.version files.

Correct?