Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

On this page:
Edit this Post

Yesterday I ran into yet another .NET Core versioning problem, this time related around the .NET Core SDK installation. A couple of days ago the .NET Core 3.0 Preview 4 SDK was released and I installed it as I was doing some experiments around Blazor and Razor Components again. I installed the SDK and did my 3.0 things and forgot about it.

Today I went back to one of my .NET Core 2.2 applications and found that when trying to run from the command line I was getting strange errors saying that the required 2.2 SDK wasn't installed.

To my surprise doing a:

dotnet --info

showed this:

All the 2.x SDKs were missing. Yet notice that the 2.x SDKs are actually installed on the machine, as you can clearly see in the Programs and Features display.

I tried a few things to try and get this to work without success:

  • Repair Installed the 2.2 SDKs
    Just to be sure I went and repaired two of the SDK installs to see if that would bring them back in the dotnet --info list - but no joy.

  • Added explicit global.json
    I created a global.json with a very specific SDK version that I know was installed. Building the project now tells me that the specific version of the SDK is not installed. Hrrrmph - no joy.

I've been having a bunch of version mishaps lately with .NET Core, so in my frustration I yelled loudly on Twitter 😇

I'll come to regret that later... but only a little 😃

Success #1: Uninstall the .NET Core 3.0 SDK

So the first and obvious solution after all the above failed was to uninstall the .NET Core 3.0 SDK and sure enough removing the SDK fixed the problem, and the 2.2 SDKs SDK list back was back!


But why all the pain with the 3.0 SDK?

32 Bit vs 64 Bit

Thanks to my Twitter outburst it only took a few minutes for Kevin Jones (@vcsjones) and Ben Adams (@ben_a_adams) to spot my myopia:

The 3.0 SDK installed is the 32 bit version and due to the way the SDK pathing worked out due to install order, the 32 bit SDK is found first.

So what happened here is that I had accidentally installed the 32 bit version of the .NET Core 3.0 SDK. If you look at the screen shot above more closely you can see that the installed version is installed Program Files (x86) which is the giveaway for the 32 bit version:

The problem here is that if you have both 32 bit and 64 bit versions of the SDK installed, the first one found wins. And only one version of the SDK (32 bit or 64 bit) can be active at any one time.

Success #2: Fix the Problem

So to fix this problem I can now do :

  • Uninstall the .NET Core 3.0 32 Bit SDK
  • Reinstall the 64 bit Version

which nets me the install I want to have from the get-go:

or if you really need to have both SDKs installed fix the path so that the one you need - the 64 bit one most likely - is first in the path sequence.

Do you need 32 Bit SDKs?

There should be very little need for 32 bit versions of the SDK on Windows. Most moderns Windows machines are running 64 bit so if you are building a new application it would make sense to build your apps using 64 bit.

One place where this will perhaps matter with .NET 3.0 is for desktop applications. A lot of older desktop applications are still 32 bit for a variety of reasons (interop with older 32 bit COM components for example), compatibility issues with older UI components.

For example, I'm planning at some point to move Markdown Monster to .NET Core 3.0 but currently it runs as a 32 bit application due to better performance and stability of the Web Browser control in 32 bit mode. As long as I continue to use that control (which may not be much longer if the new Chromium Edge WebView can work reliably) I will continue to keep the application running as a 32 bit app.

So there are still some edge cases for 32 bit development and that's what those SDK exist for I suspect.

But... even if you are building 32 bit apps, according to Rich Lander again, the 64 bit SDK can build for 32 bit runtimes so even if you are building a 32 bit application you probably don't need a 32 bit SDK.

All 64 bit, all day!

Make it harder to install 32 bit

So my fat fingered error was caused by being sloppy when picking the installer on the Web Page:

It's probably a good idea to make the 64 bit download more prominent to avoid an accidental click or even for a new .NET person to think that x86 might just fine.

Even better maybe the 32 bit download on a 64 bit system should prompt and ask Are you sure you want to install the 32 bit SDK?

Watch out for the IIS Server Hosting Pack!

I ran into another problem with x86 and x64 a day later when I installed an update to the IIS Server Hosting pack on a server. The hosting pack installs both 32 bit and 64 bit versions and for reasons unknown I found that when I installed the latest version, dotnet --info only reports the 32 bit versions when running. Same issue as above, somehow the 32 bit path preceeded the 64 bit path causing only the 32 bit runtimes to show up.

I actually found that some of my applications were running in 32 bit mode, which I guess is not a huge problem, but somewhat unexpected. For the quick fix - I ended up uninstalling the 32 bit runtimes that the Hosting Pack(s) past and future installed.

Visual Studio doesn't Care

Incidentally I found that while I was struggling on the command line with the dotnet command line tooling, Visual Studio was just fine compiling my 2.2 projects and running it. The problem I had was specifically with the command line version from my 'normal' Windows environment.

It works for Visual Studio because VS sets up a custom environment with a custom path that includes the right SDK locations based on the runtime target you specify in your application, so compilation inside Visual Studio works.

So in theory I could have gone and published my project to a folder to get the output to work. But then running it locally I still would have to adjust my path (unless I run through Visual Studio).

Moral of the Story

At the end of the day this was a user error on my part. The bottom line is make sure you install the right version of the .NET Core SDK and runtimes.

In almost all cases the right version of the SDK to download and is the 64 bit version unless you are running on 32 bit Windows version (hopefully not).

this post created and published with Markdown Monster
Posted in .NET  

The Voices of Reason


Lex Li
April 21, 2019

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

Thanks! I just realized that I hit the same issue, though my workaround was to always use "%ProgramFiles%\dotnet\dotnet.exe" instead of just dotnet in commands. Finally know the cause and now I can fix it.

April 22, 2019

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

Thanks for the great write-up. As far as bitness and the IIS Server Hosting Pack, the guidance for preferring 32-bit applications and (application pools) is still unchanged after all these years. Time to revisit?


Supported platforms

Apps published for 32-bit (x86) and 64-bit (x64) deployment are supported. Deploy a 32-bit app unless the app:

  • Requires the larger virtual memory address space available to a 64-bit app.

  • Requires the larger IIS stack size.

  • Has 64-bit native dependencies.

Rick Strahl
April 22, 2019

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

@JH - yeah that's an interesting point. I do run all my classic ASP.NET applications in 32 bit - less memory usage and last I tested better performance (although that's been a while). I suspect though that .NET Core is optimized better for 64 bit and going forward I think it'll be all 64 bit, so better to try go with that for the future IMHO.

Dan Narsavage
May 06, 2019

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

Thanks for this great write-up! FWIW, I had to uninstall ALL x86 versions of the SDK & runtime before ANY x64 stuff would show up in the CLI.

February 19, 2020

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

You saved my day today. You have to uninstall all X86 SDK's and Runtime's!. Or an easier solution: remove the reference to Program files (X86)/dotnet/SDK from your PATH environment variable.

Ryan Armstrong
May 29, 2020

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

TL;DR Update Visual Studio to a new release.

I found a helpful solution for anyone unfortunate enough to be stuck on older SDKs like I am, and having unit test issues. https://developercommunity.visualstudio.com/content/problem/831442/test-explorer-wont-run-tests-too-particular-about.html

July 08, 2021

# re: Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit

To fix it without re-installing, just move the x86 dotnet path below the x64 dito in the PATH environment variable.

win → "edit system environment variables" (or something similar) → Environment Variables → System variables → select PATH → edit →

find the "C:\Program Files (x86)\dotnet" path and move it below the "C:\Program Files\dotnet" path.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024