Sdk: Windows Installer should not provide option to change install path

[TheRealPiotrP]

Steps to reproduce

Run the Windows installer.

Expected behavior

No option to change installation directory

Actual behavior

Option to change installation directory. Setting this option is a null-op, simply frustrating users.

Environment data

dotnet --info output:

1.0.0-preview2-003067

[lt72]

I disagree that we should not provide the option. For one I like to install my tools in the path I choose for myself.
Maybe the option should have a default...

[ericstj]

@lt72 maybe the zip is for you

[nil4]

@ericstj thank you for your considerate suggestion! If one can use the zip to install to a custom location, what is the downside of letting MSI users select the desired location? What may I be missing here?

[ericstj]

downside of letting MSI users select the desired location

That's not what it's for.

The MSI is the machine-wide product. It's meant to be used when you want CLI centrally installed to a known location. If CLI were to allow that to be re-targeted then everything that "knows" about the central install would have to be changed to look up a dynamic location and we'd have to register that dynamic location. Here's a few things that come to mind that would need to "know": VS, host, other MSIs that extend/compose CLI, updates to the CLI. In general this would add a lot of complexity to the installers for a scenario that you can already achieve with the zip.

I'm not saying that we shouldn't permit dynamic locations of the CLI. It's definitely a scenario we care about which is why the ZIPs exist. I just think that it's a ton of busy work and a bug farm to try and make the MSIs install to a dynamic location and have that consistent across everything. Not to mention that dynamic paths are terrible in MSI when it comes to component ref-counting. /cc @robmen

[robmen]

I think @ericstj's statement about dynamic paths messing up component ref-counting might be overstated a bit. The Windows Installer does fine putting Components in different folders. It's shared resources (usually registry keys) that point at those folders that have problems. No shared resources? Ref-counting shouldn't be a problem. I haven't checked but given the "SxS everything" design of CLI I wouldn't expect any shared resources.

However, I do think @ericstj might _understate_ the testing overhead you get with additional configuration. "bug farm" is a good way to describe it. You have to really want the configuration to bother testing it. Remember, it's not so much testing the current version that is usually what kills you. It's testing against the appropriate number of previous versions (-1, -2, -3, ...?) and potentially future versions (yes, the ones you haven't built yet) to make sure nothing is broken.

Finally, configuration in "platform software" (dotnet/cli is on the bubble of "platform") is generally a no-no. No one wants to deal with the possibility that the "platform" is installed differently on different machines.

Ultimately, I'm of the mind that unless your product is large and you need to worry about eating too much disk space on one drive, it isn't worth configuring the installation folder. And if you're "platform software" minimize configuration to zero.

PS: Remember, .NET Framework requires a couple GB+ on your system drive, no option to change that install location.

[nil4]

The MSI is the machine-wide product.

In what sense is it a machine-wide product? The installation is local to the target folder, whether that's under Program Files or somewhere else. The only machine-wide resource updated (apart from the MSI installer databases) is the path. In fact, that's exactly what someone installing from the zip file is expected to do to make dotnet available, i.e. add it manually to the path. Which shared components I am missing?

Also, it is unclear how this decision relates to the Porting to .NET Core blog post:

But even if you stay on Windows you may want to take a look at ASP.NET Core because it offers new features and doesn’t require a machine wide framework installation, which avoids issues such as requiring machine changes, administrative privileges during deployment, and GAC policies.

It seems to me like none of the benefits stated above are actually delivered by way of this decision. /cc @terrajobst

[ericstj]

In what sense is it a machine-wide product?

That's the purpose of the MSI. That is what it is for. If you don't want machine wide, don't use the MSI.

none of the benefits stated above are actually delivered

@nil4 they certainly are. You don't have to install the MSI. You can deploy .NET Core inside your own application as a standalone app or use the ZIP to put the whole SDK in whatever folder you want. MSI is unnecessary overhead for non-machine-wide deployment. If folks think the zip scenario requires too many manual steps then I think that's a fine thing to invest in (eg: add a way for CLI to do some user registration when deployed as a zip such as add to path). I don't think trying to make the MSI have a "dynamic mode" is the right investment.

@robmen the component refcounting issues I was alluding to have to do with patch/reinstall/uninstall ops. If any session doesn't calculate the right dynamic path that the product was installed to originally you can orphan components and leave product in advertised state. This becomes especially complicated when you have many products that all need share the same dynamic path.

[livarcocc]

The option is no longer there

[brianjlacy]

I'm installing .NET Core SDK 1.1.9 and it is asking me the install location -- it has NO default provided. I have no idea where I should properly install it.

[livarcocc]

The option has been removed in 2.0.

[danielvlasceanu]

In my opinion, the path should be somehow configurable, via UI, at installation time (in which case it should provide a default path), or an environment variable. I had to move the Program Files\dotnet folder to another disk and changed the dotnet variable accordingly, and all worked well. Until I installed another version of .NET Core SDK and wondered why on Earth isn't Visual Studio picking it up?

[peterhuene]

@johnbeisner we addressed this in 3.0, correct?

[ushahx]

I was able to resolve the issue where I could not see Target Framework for .NET Code 3.1 (3.1.3) in the selection drop down. I could see all the SDKs under the folder C:\Program Files\dotnet\sdk but they were all missing under C:\Program Files (x86)\dotnet\sdk and even in the list when I try the "dotnet --list-sdk" in command prompt. The trick was to install the x86 version of the SDK you need. I installed the x86 version of 3.1.302 I was now able to see 3.1 in the target framework under project properties. Make sure you close VS before installing.