Visual Studio 2019 Was "Unable to Locate .NET Core SDK"

Earlier today I noticed that Visual Studio 2019 (v16.11.5) could not load any of my .NET Core projects projects. When I tried to reload any of them, I got an error saying that "The project file cannot be opened. Unable to locate the .NET SDK" in the output pane, and then nothing happened.

A google search yielded suggestions saying that the version 2.x.xxx .NET Core SDK needed to be installed. Some said that "C:\Program Files\dotnet\" needed to be part of the "PATH" environment variable. Another said that an old "global.json" file was the cause. While each of these solutions worked for some folks, none seemed to work for me. I ran "dotnet --info" on the command line, and this is what I saw:

"No SDKs were found." Then I noticed a comment about x86 version of dotnet at https://superuser.com/questions/1431833/visual-studio-2019-unable-to-locate-net-core-sdk/1441219. I realized that I was running the x86 version of dotnet. Of course, in hindsight, the "C:\Program Files (x86)" paths in the runtime locations should have been a clear indication of the problem. Then I tried running the 64 bit version:

Well, now a whole list of SDKs showed up. It turned out that the paths to both the x86 version of dotnet and the 64 bit dotnet were in my "PATH" environment variable, and the x86 version was listed first. I do not know which installer made this change, for the projects were working fine at one time. I removed the path to the x86 version of dotnet from the "PATH" environment variable, and now everything works fine.

One interesting side-note: Window 11 complained about the size of the "PATH" environment variable, saying that its length had exceeded 2048. I replaced some folder paths with environment variable references, and reduced the length to below 2048. I wondered: when installer apps increased the "PATH" environment variable length to beyond 2048, why did not Windows complain? Would Windows just ignore the part after the first 2048 characters? Or would Windows use the whole "PATH" environment variable, even though its length exceeded 2048, just because some installer app did this? It turns out that a "PATH" environment variable longer than 2048 can cause real problems: https://superuser.com/questions/355594/windows-7s-path-and-environment-variables-are-corrupted, at least for older versions of Windows. For Windows 10, there is a discussion here: https://stackoverflow.com/questions/34491244/environment-variable-is-too-large-on-windows-10. From the look of the error dialog box, this should apply to Windows 11 as well.

Getting Rid of the Annoying Air Gaps Along the Edges of a Tempered Glass Screen Protector on a Cell Phone

Installing tempered glass screen protectors on cell phones always takes a lot of patience, and the results are usually less than ideal: dust particles under the tempered glass screen protectors can leave air bubbles around them. Repeatedly lifting the tempered glass screen protector to get rid of the dust particles can leave air gaps along the edges of the tempered glass screen protectors that would not go away.

I found two things that could help in such situations:

1. Install the tempered glass screen protectors in a large, thin new transparent plastic gap. Rubbing the plastic bag to introduce some static charges onto the bag would reduce the amount of dust particles floating in the bag. By placing all necessary components needed for the installation into the bag gently, you would have a less dusty environment for installation.

2. After the installation of a tempered glass screen protector, if you see air gaps along the edges of the tempered glass screen protector, you can use a cotton swab soaked with distilled water (but not dripping), and dab it along an air gap to get the water into the gap. Once the water is in the air gap, press the tempered glass along the area where the air gap was to squeeze out the water. Clean off any water that you see. The air gap will be gone for good.