dotnet-sdk-8.0.425-win-x64.exe is the Windows x64 installer of .NET SDK 8.0.425: dotnet-sdk, the version, the OS, the architecture. Three routes get you one exact SDK on Windows: winget with --version, that installer file, or dotnet-install.ps1 -Version into a folder of your own. On a Windows 11 PC with four SDKs, each was traced to its real file and dotnet-install was run for real, after the check that often makes the install unnecessary.

Do it yourself
  1. dotnet --list-sdks, then dotnet --version in the project folder
  2. If the pin already resolves to an SDK you have, stop
  3. winget show Microsoft.DotNet.SDK.8 --versions lists every patch; --version 8.0.425 prints its installer
  4. Machine-wide: winget install Microsoft.DotNet.SDK.8 --version 8.0.425 or the .exe from the .NET 8.0 page
  5. Side by side: .\dotnet-install.ps1 -Version 8.0.425 -InstallDir a short folder -NoPath
  6. Point the repository at it with a global.json paths entry, or put it first on PATH
  7. Confirm with dotnet --version

Check first: you may not need it

This PC has no 8.0.425. A global.json asking for it, with no rollForward, still worked:

> type global.json
{
  "sdk": {
    "version": "8.0.425"
  }
}
> dotnet --version
8.0.426

With no policy the host uses patch: the exact version, or else the latest patch of the same feature band (the 4 in 425). Only "rollForward": "disable" demands the exact build, and then the host refuses with A compatible .NET SDK was not found., covered in the Fixes post. A pin of 8.0.400 with latestPatch also landed on 8.0.426, and dotnet --info names the SDK and the file that chose it: 

.NET SDK:
 Version:           8.0.426
 Commit:            a021cd4eac
...
global.json file:
  C:\Users\...\fixes5\sdk\g-latestpatch\global.json

DOTNET_ROLL_FORWARD=LatestMajor did not rescue the disable pin; it picks an app's runtime, not the SDK.

Which file is dotnet-sdk-8.0.425-win-x64.exe?

The .NET 8.0 download page, read on October 22, 2026, lists SDK 8.0.425 under the 8.0.31 release of September 8; the current SDK is 8.0.426 with runtime 8.0.32, from October 13. On the 10.0 page, 10.0.401 sits under 10.0.12, also September 8, and the current SDK is 10.0.402. The x64 installer links resolve to: 

https://builds.dotnet.microsoft.com/dotnet/Sdk/8.0.425/dotnet-sdk-8.0.425-win-x64.exe
https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.401/dotnet-sdk-10.0.401-win-x64.exe

Both answered a HEAD request with 200; the 8.0.425 file is 225,549,280 bytes. The downloads page ends support for .NET 8 and .NET 9 on November 10, 2026. Microsoft's install page adds that the installers remove the previous installation after installing the new one; from 8.0.11 a RemovePreviousVersion registry value can defer or prevent that. No installer was run on this PC.

winget: every patch is there

> winget search Microsoft.DotNet.SDK --source winget --disable-interactivity
Name                            Id                           Version
------------------------------------------------------------------------------------
Microsoft .NET SDK 10.0         Microsoft.DotNet.SDK.10      10.0.402
Microsoft .NET SDK 3.1          Microsoft.DotNet.SDK.3_1     3.1.426
Microsoft .NET SDK 5.0          Microsoft.DotNet.SDK.5       5.0.408
Microsoft .NET SDK 6.0          Microsoft.DotNet.SDK.6       6.0.428
Microsoft .NET SDK 7.0          Microsoft.DotNet.SDK.7       7.0.410
Microsoft .NET SDK 8.0          Microsoft.DotNet.SDK.8       8.0.426
Microsoft .NET SDK 9.0          Microsoft.DotNet.SDK.9       9.0.319
Microsoft .NET SDK 11.0 Preview Microsoft.DotNet.SDK.Preview 11.0.100-rc.2.26504.105

Search shows the latest of each, but winget show Microsoft.DotNet.SDK.8 --versions printed 85 versions, 8.0.426 down to 8.0.100, and naming one prints its installer: 

> winget show Microsoft.DotNet.SDK.8 --version 8.0.425 --source winget --disable-interactivity
Found Microsoft .NET SDK 8.0 [Microsoft.DotNet.SDK.8]
Version: 8.0.425
...
  Installer Type: burn
  Installer Url: https://download.microsoft.com/download/4df5e4e8-4c5f-4fa6-9730-c51e177fb61b/dc7c534c-bf24-48ca-943d-d849785c5d12/dotnet-sdk-8.0.425-win-x64.exe

Same file name, another host. So winget install Microsoft.DotNet.SDK.8 --version 8.0.425 asks for exactly that build ("Use the specified version", says winget 1.29.380's help). It was not run here: winget list shows that package at 8.0.426 on this PC, and what winget does with an older version of an installed package was not tested.

dotnet-install.ps1: a side-by-side copy

Microsoft's script unpacks the zip build of an SDK into any folder without admin rights. Its documentation aims it at CI and sends development machines to the installers, yet it is the only route that leaves the machine-wide SDKs alone. A dry run: 

> .\dotnet-install.ps1 -Version 8.0.425 -DryRun
dotnet-install: Payload URLs:
dotnet-install: URL #0 - primary: https://builds.dotnet.microsoft.com/dotnet/Sdk/8.0.425/dotnet-sdk-8.0.425-win-x64.zip
dotnet-install: Repeatable invocation: .\dotnet-install.ps1 -Version "8.0.425" -InstallDir "C:\Users\...\AppData\Local\Microsoft\dotnet" -Architecture "x64"

Same folder as the .exe, a .zip instead; the default target is %LocalAppData%\Microsoft\dotnet. -Channel 8.0 resolved to 8.0.426, so -Version is what pins. The first real run, into a deep folder, failed: 

> .\dotnet-install.ps1 -Version 8.0.425 -InstallDir C:\Users\...\scratchpad\fixes5\sdk\dotnet-test -NoPath
dotnet-install: Extracting the archive.
dotnet-install: Failed to extract package. Exception: Exception calling "ExtractToFile" with "3" argument(s): "Could not find a part of the path ...

That folder was 134 characters and the file it stopped on 126 more: 261, past the 260-character limit, under Windows PowerShell 5.1. The longest file in the zip is 169 characters below the root, so keep the folder under about 90; the default qualifies. The failed run also left its 285 MB download in %TEMP%. A short folder took 26 seconds: 

> .\dotnet-install.ps1 -Version 8.0.425 -InstallDir $env:TEMP\fix5-sdk\dn8 -NoPath
dotnet-install: Downloaded file https://builds.dotnet.microsoft.com/dotnet/Sdk/8.0.425/dotnet-sdk-8.0.425-win-x64.zip size is 285157731 bytes.
dotnet-install: Installed version is 8.0.425
dotnet-install: Installation finished

The result: 5,140 files, about 750 MB, with its own runtime 8.0.31. -NoPath keeps the folder off the session's PATH; the documentation says the script never sets the user's PATH or DOTNET_ROOT.

Using the side-by-side SDK

The folder's dotnet.exe sees only its own SDK, and the Program Files one does not see the folder. In a folder whose global.json demands exactly 8.0.425, putting the SDK folder first on PATH worked: where dotnet listed it first and dotnet --version printed 8.0.425. DOTNET_ROOT did not; it tells an app's launcher where the runtimes are, as a net8.0 console app shows (cmd syntax; fix5-sdk\dn8 and RtProbe are this test's names): 

> bin\Release\net8.0\RtProbe.exe
Runtime: .NET 8.0.32
From: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.32
> set DOTNET_ROOT=%TEMP%\fix5-sdk\dn8& bin\Release\net8.0\RtProbe.exe
Runtime: .NET 8.0.31
From: C:\Users\...\AppData\Local\Temp\fix5-sdk\dn8\shared\Microsoft.NETCore.App\8.0.31

The third way is new in the .NET 10 SDK, a paths array in global.json, and with it the Program Files dotnet found the copy: 

{
  "sdk": {
    "version": "8.0.425",
    "rollForward": "disable",
    "paths": [ "C:/Users/.../Temp/fix5-sdk/dn8", "$host$" ],
    "errorMessage": "SDK 8.0.425 is missing. Run dotnet-install.ps1 -Version 8.0.425 first."
  }
}
> where dotnet& dotnet --version
C:\Program Files\dotnet\dotnet.exe
8.0.425

$host$ is the running dotnet's folder, and the documentation says "the first matching SDK is used": with $host$ first and no policy, the same pin picked 8.0.426. A missing version printed the errorMessage. Builds used the copy too (NETCoreSdkVersion 8.0.425); dotnet --info printed a KeyNotFoundException for workload 'android'.

In WSL

WSL has its own SDKs: Part 2 of the Windows setup series got 10.0.112 from Ubuntu 24.04's feed, while Windows here runs 10.0.402. A pin of 10.0.402 cannot resolve to it under any policy, because roll-forward only moves up (on Windows, 9.0.400 with latestFeature failed beside 9.0.317). For an exact version on Linux, dotnet-install.sh takes --version and --install-dir (not run here).

Frequently asked

What is dotnet-sdk-8.0.425-win-x64.exe?
The Windows installer for .NET SDK 8.0.425 on 64-bit x64 Windows: dotnet-sdk, the SDK version, win and the architecture. The .NET 8.0 download page lists it under the 8.0.31 release of September 8, 2026, and its link resolves to builds.dotnet.microsoft.com/dotnet/Sdk/8.0.425/. winget's Microsoft.DotNet.SDK.8 package at version 8.0.425 points to a file of the same name.
How do I install a specific .NET SDK version with winget?
winget install Microsoft.DotNet.SDK.8 --version 8.0.425. The package id carries the major version, and winget show Microsoft.DotNet.SDK.8 --versions lists every published patch: 85 for .NET 8 on October 22, 2026, from 8.0.100 to 8.0.426. Microsoft's install page says WinGet installs are system-wide.
Does DOTNET_ROLL_FORWARD change which .NET SDK is used?
No. With DOTNET_ROLL_FORWARD=LatestMajor set, a global.json demanding SDK 8.0.425 exactly still failed with A compatible .NET SDK was not found. The SDK is chosen by the version and rollForward in global.json; DOTNET_ROLL_FORWARD decides which runtime runs an app when the one it was built for is missing.

Which SDK builds a project and which runtime runs it is Part 1 of Set Up a Windows PC for .NET Development. A pin too old for the project ends in NETSDK1045.