joeloff
commented
4 years ago I don't think this is an SDK issue. Installing the SDK will install the matching runtime. However, by installing the hosting bundle, you're effectively bringing in both x86 and x64 runtimes which will modify path environment variables and that's likely why the workaround after step 4 in the original post was necessary
@aleha84 commented on Tue Jan 02 2018
Installing https://download.microsoft.com/download/2/B/2/2B2854E7-7EAE-4FE9-85D2-19ACCD716F18/DotNetCore.2.0.4-WindowsHosting.exe just after https://download.microsoft.com/download/2/9/3/293BC432-348C-4D1C-B628-5AC8AB7FA162/dotnet-sdk-2.1.3-win-x64.exe cause error : The SDK 'Microsoft.NET.Sdk.Web' specified could not be found in Visual Studio 2017 for existing and new projects targeting .Net Core 1.1 or 2.0. Also after this it looks like system is missing for SDK completely. Command dotnet --version produces:
Test environment: Windows 10 Home x64. Steps to reproduce:
Workaroud: After step 4 open Control Panel -> Programs And Features -> Remove Microsoft .NET Core Runtime 2.0.4 (x86). dotnet --version. Output: 2.1.3 Projects in VS2017 opens and creates normally.
@Petermarcu commented on Tue Jan 02 2018
@joeloff
@joeloff commented on Thu Jan 04 2018
Are the runtime installers mucking with environment variables? The hosting bundle itself makes no changes to the environment, but it will attempt to install both x86 and x64 versions of the runtime. It's intended to be a single bundle that provides as much as can be installed.
@aleha84 commented on Thu Jan 04 2018
I did not check these details. At some point, when I was looking for solutions, checked environment variable Path in User section, and not found there paths to dotnet, in the system variables they were present. Added them by hands. But it seems not helped at all.
@dasMulli commented on Thu Jan 04 2018
You could type
where dotnetto check which path is listed first. If it is the 32bit path, then it won't find the 64bit sdk. If so, you could fix this by changing the order of the entries in the PATH environment variable..@aleha84 commented on Thu Jan 04 2018
Right now, when everithing works fine:
where dotnetproduces:C:\Program Files\dotnet\dotnet.exe, it is 64 bit sdk. If no one can reproduce an example described by me, then this is exclusively my personal case, and I'll just know that after installation of "hosting bundle" I'll delete x86 runtime@joeloff commented on Mon Jan 08 2018
@aleha84 did you have previous hosting bundles installed before 2.0.4? In earlier versions of the hosting bundles we used to install the x86 runtime first. We've changed the order in later releases to run x64 first if it applies. However, if the runtime environment variables were previously configured, new runtime installs won't change their order since they already exist and the work around would be to manually change them under you system settings.
The hosting bundle also supports a command line switch, OPT_NO_X86. When you run the installer from the commandline and pass OPT_NO_X86=1, then it will only install the 64-bit runtime
@aleha84 commented on Mon Jan 08 2018
yes, previously i installed 1.1.4 and 1.1.5 versions. But i removed them all.
@joeloff commented on Mon Jan 08 2018
Ok, so that might explain the issue. The hosting bundle actually wraps the runtime bundle. However the runtime bundles themselves don't actually remove the runtimes when they are uninstalled. You have to manually uninstall the runtimes (the bundles for the runtime actually wrap 3 separate windows installer packages).
@aleha84 commented on Mon Jan 08 2018
As i described in step 1 to reproduce, I uninstalled all .Net Core components, such as SDK, Runtimes and hosting.
@Petermarcu commented on Fri Mar 23 2018
@Eilon do you know which repo this should be tracked in?
@joeloff commented on Fri Mar 23 2018
This almost sounds that the 2.0.x and 2.1.x runtime/SDK installers aren't playing together in SxS situations.
@Petermarcu commented on Fri Mar 23 2018
@rakeshsinghranchi @wli3