dot net core 3.1 sdk installer (windows 10) not working

[NTiering]

Describe the bug
dot net core 3.1 sdk installer (windows 10) not working

To Reproduce
1 .Downloaded and run dotnet-sdk-3.1.100-preview1-014459-win-x86.exe. No errors and runs to finish

Expected behavior
dotnet sdk 3.1 should be listed in dotnet --list-sdks
dotnet sdk 3.1 should be listed in C:\Program Files\dotnet\sdk

Additional context
Re running the installer offers a repair option, and runs without error, but does not install 3.1

[dagood]

I think weirdness like this is expected to happen if you have both x86 and x64 SDKs installed:

1. Run Windows 10 x64.
2. Install some x64 .NET Core SDK.
3. Install this x86 SDK.
   • At this point, there are two dotnet.exes installed: one for each architecture. Each one is limited to finding SDKs and Runtimes that match its architecture.
   • Which dotnet.exe is used to run dotnet commands depends on which one is first in the PATH environment variable. The one that is installed first wins, based on the logic in host.wxs.
4. dotnet --list-sdks only finds the x64 SDKs you have installed, not the x86 ones.

Maybe this could be improved... seems like it could be complicated to make sure changes don't create bad expectations (expecting that the x64 dotnet can run the x86 SDK, ...) or cover every scenario. I don't have particularly deep knowledge of this component.

This repo is the right place--if there are improvements, I believe they'd be in the dotnet host logic.

[dagood]

@vitek-karas, can you take a look?

[vitek-karas]

I personally think that the behavior is correct in the sense that depending on which dotnet.exe is used only the frameworks/SDKs of that bitness should be available. That said I agree that the error experience can be improved a lot.

I can imagine doing things like:

• If we fail to find a given framework/SDK, look also into the other bitness and if it's there report a very specific error ("You're running 32bit, but the framework you want is 64bit. Make you run the right bitness or install the framework for 32bit as well")
• --list-sdks, --info and --list-runtimes should also look into the other bitness and list it in a separate section - making the distinction obvious.
• In all the related errors be very specific which bitness is used and where we looked (at least roughly) - to make it clear what we tried to actually run.

@elinor-fung

[asulwer]

when i changed my environment variables order that fixed it. Issue was i couldnt target core 3.1 only saw 3.0 because my environment variable had x86 before x64, moved it around and now i can target 3.1

[Rick-Anderson]

Can you reopen this and address the issue? There are over 20 SO threads on this. It's a big problem. I made a clean answer at https://stackoverflow.com/questions/67049414/the-latest-installed-net-sdk-not-found/67049415

The .NET SDT installed needs to detect which path variable is first and issue a warning when appropriate.
Related #4531

[vitek-karas]

@Rick-Anderson can you please describe in more detail what you want to get fixed here? You mean that the x64 version should be aware of x86 and somehow hint the user how to get to the x86 (and vice versa)?

[Rick-Anderson]

The installer should be aware of the path variable so if you're installing a different bit version, you can be warned that this installation won't be used unless you manually edit/fix the path . It's not x64 only, it's both. If the path variable is already set for another bitness, return a link to a help doc. Some of the SO answers have the wrong answer to the problem

There are many SO questions on this.

I personally think that the behavior is correct in the sense that depending on which dotnet.exe is used only the frameworks/SDKs of that bitness should be available. That said I agree that the error experience can be improved a lot.

How often do folks intentionally install 2 different bitness to control which is being used? That's an advanced scenario and shouldn't drive the default behavior.

--list-sdks, --info and --list-runtimes should throw a huge warning and link to the doc I suggested. But really this is too late, you should be warned on installation. That's a great backup help for those folks who ignore the warning the installer returns. If you read the SO posts, folks run those tools are are mystified .

Can you reopen this issue, or do you mind if I reopen it?

The following seem like great ideas.

I can imagine doing things like:

• If we fail to find a given framework/SDK, look also into the other bitness and if it's there report a very specific error ("You're running 32bit, but the framework you want is 64bit. Make you run the right bitness or install the framework for 32bit as well")
• --list-sdks, --info and --list-runtimes should also look into the other bitness and list it in a separate section - making the distinction obvious.
• In all the related errors be very specific which bitness is used and where we looked (at least roughly) - to make it clear what we tried to actually run.

[vitek-karas]

Thanks a lot @Rick-Anderson. I created separate issues for the various parts of the product which should improve to provide optimal UX:

• Installers should be aware of multi-arch OSes and warn users as appropriate installer#10192 the installer issue to warn users of PATH collisions
• Host should inform user about other installed archs on the system #51101 the dotnet --info improvement
• Host should inform user about different archs when failing to find framework #51102 improving error messages when failing to run an app

This is also very much related to all the work described in #50798