X64 .net 6.0 Runtime

[Olowookere Devost]

Thereare many different ways to install .NET on Windows. This article helps you understand the difference between the SDK and Runtime, which runtime you should install, and the method you should use to install .NET.

Unlike .NET Framework, .NET isn't installed and tied to your version of Windows. You can only have a single version of .NET Framework installed on Windows. .NET can be installed anywhere on your computer and some apps might include their own copy of .NET.

There are three different runtimes for Windows, which enable different types of apps to run. The SDK includes all three runtimes. If you install a specific runtime, it might include other runtimes. The following table describes which runtime is included with a particular .NET installer:

To ensure that you can run all .NET apps on Windows, install both the ASP.NET Core Runtime and the .NET Desktop Runtime. The ASP.NET Core Runtime runs any web apps, and the .NET Desktop Runtime runs any desktop app, such as a Windows Presentation Foundation (WPF) or Windows Forms (WinForms) app.

There are different ways to install .NET, and some products, like Visual Studio, might manage their own version of .NET. If you install .NET through software that manages its own version of .NET, you should also install the .NET runtime separately so that you can run .NET apps.

Use Visual Studio to install .NET when you want to develop .NET apps using Visual Studio. Visual Studio manages its own copy of .NET. This method installs the SDK, Runtime, and Visual Studio templates.

The following table is a list of currently supported .NET releases and the versions of Windows they're supported on. These versions remain supported until either the version of .NET reaches end-of-support or the version of Windows reaches end-of-life.

While Windows 2012 is still supported with the latest version of .NET, .NET 6 was the last version to support Windows 7 and Windows 8.1. All three of these versions of Windows require further dependencies to be installed:

On an Arm-based Windows PC, all Arm64 versions of .NET are installed to the normal C:\Program Files\dotnet\ folder. However, the x64 version of the .NET SDK is installed to the C:\Program Files\dotnet\x64\ folder.

The x64 .NET SDK installs to its own directory, as described in the previous section. This allows the Arm64 and x64 versions of the .NET SDK to exist on the same machine. However, any x64 SDK older than 6.0, isn't supported and installs to the same location as the Arm64 version, the C:\Program Files\dotnet\ folder. If you want to install an unsupported x64 SDK, you must uninstall the Arm64 version first. The opposite is also true. You must uninstall the unsupported x64 SDK to install the Arm64 version.

Environment variables that add .NET to system path, such as the PATH variable, might need to be changed if you have both the x64 and Arm64 versions of the .NET SDK installed. Additionally, some tools rely on the DOTNET_ROOT environment variable, which would also need to be updated to point to the appropriate .NET SDK installation folder.

Visual Studio installs its own copy of .NET separate from other copies of .NET. Different versions of Visual Studio support different versions of .NET. The latest version of Visual Studio always supports the latest version of .NET.

Visual Studio Installer installs and configures Visual Studio. Some Visual Studio workloads include .NET, such as ASP.NET and web development and .NET Multi-platform App UI development. Specific versions of .NET can be installed through the Individual Components tab.

Visual Studio Code uses the versions of .NET already installed on your system. Install .NET using either .NET Installer or Windows Package Manager. Visual Studio installs its own copy of .NET that can't be used by Visual Studio Code.

You can install and manage .NET through the Windows Package Manager service, using the winget.exe tool. For more information about how to install and use WinGet, see Use the winget tool to install and manage applications.

Installing .NET through the dotnet-install PowerShell script is recommended for continuous integration and nonadmin installs. If you're installing .NET for normal use on your system, use either the .NET Installer or Windows Package Manager installation methods.

The script defaults to installing the latest long term support (LTS) version, which is .NET 8. You can choose a specific release by specifying the -Channel switch. Include the -Runtime switch to install a runtime. Otherwise, the script installs the SDK. The script is available at -install.ps1 and the source code is hosted on GitHub.

After downloading an installer, verify it to make sure that the file hasn't been changed or corrupted. You can verify the checksum on your computer and then compare it to what was reported on the download website.

You can use PowerShell or Command Prompt to validate the checksum of the file you've downloaded. For example, the following command reports the checksum of the dotnet-sdk-8.0.100-win-x64.exe file:

The .NET release notes contain a link to a checksum file you can use to validate your downloaded file. The following steps describe how to download the checksum file and validate a .NET install binary:

The release notes page for .NET 8 on GitHub at -notes/8.0 contains a section named Releases. The table in that section links to the downloads and checksum files for each .NET 8 release:

Most likely you installed both the x86 (32-bit) and x64 (64-bit) versions of the .NET SDK. This is causing a conflict because when you run the dotnet command, it's resolving to the x86 version when it should resolve to the x64 version. This problem is fixed by adjusting the %PATH% variable to resolve the x64 version first.

Verify that you have both versions installed by running the where.exe dotnet command. If you do, you should see an entry for both the Program Files\ and Program Files (x86)\ folders. If the Program Files (x86)\ folder is first, as demonstrated by the following example, it's incorrect and you should continue on to the next step.

Ensure that Smart App Control, a Windows feature, is off. Smart App Control isn't recommended to be enabled on machines used for development. Any setting other than "off" might negatively affect SDK performance.

This is on a Windows Server 2003 R2 Standard Edition box. Googling this error hasn't turned up anything pertinent. For example, this isn't occurring in VS Studio, but instead on a production box; when the service was eventually restarted, it experienced no further problems.

That's a nasty one, ExecutionEngineException. Starting with .NET 4.0, this exception immediately terminates the program. The generic cause is corruption of the state of the garbage collected heap. Which in turn is invariably caused by unmanaged code. The exact location in code at which this exception is raised isn't helpful, the corruption usually occurred well before the damage is detected.

Finding the exact cause for this is going to be difficult. Review any unmanaged code your service might be using. Suspect environmental problems if there is no obvious candidate, misbehaving malware scanners are notorious. If it repeats very poorly then suspect hardware problems like soft RAM errors.

I've experienced "internal errors" in the .NET runtime that turned out to be caused by bugs in my code; don't think that just because it was an "internal error" in the .NET runtime that there isn't a bug in your code as the root cause. Always always always blame your own code before you blame someone else's.

A: We were receiving a similar error, but we believe ours was caused by the Citrix memory optimizer.

The resolution was to force a regeneration of the .Net core libraries on the host(s) where the issue was occurring:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

For those arriving here from google, I've eventually come across this SO question, and this specific answer solved my problem. I've contacted Microsoft for the hotfix through the live chat on support.microsoft.com and they sent me a link to the hotfix by email.

I had previously been "fixing" it by forcing the garbage collector to run in server mode (gcServer enabled="true" in app.config) as described in the Microsoft article linked to by Think Before Coding. This in essence forces all threads in the application to pause during the collection removing the possibility of other threads accessing the memory being manipulated by the GC. I am happy to find that my years of searching in vain for a "bug" in my code or other 3rd party unmanaged libraries were only fruitless because the bug lay in Microsoft's code, not mine.

Application popup: Windows - Virtual Memory Minimum Too Low : Your system is low on virtual memory. Windows is increasing the size of your virtual memory paging file. During this process, memory requests for some applications may be denied.

In my case the problem was a C++/CLI library in which there was a call to the NtQuerySystemInformation; for some kind of reason sometimes (and under mysterious circumstances), when it was called the CLR heap got corrupted and the application crashed.

This happened to me after my PC automatically ngen'ed updated .NET dlls from a windows update. Something went wrong during the ngen, and many things that use .NET, including powershell and the Hyper-V MMC GUI, would quickly crash.

The machine run Windows 8.1, with .NET Framework 4.0 installed and without the 4.5 version. As it seemed from the internet that it could be also a bug in .NET 4, I tried installing .NET Framework 4.5.2 and I solved the issue.

Having worked for 7 years on the .NET runtime team, I can attest that the BOTR is the official reference. It was created as documentation for the engineering team, by the engineering team. And it was (supposed to be) kept up to date any time a new feature was added or changed.

3a8082e126