# .NET SDK for Windows PC

- **Name:** .NET SDK for Windows PC
- **Version:** 10.0.100
- **Developer:** Microsoft
- **License:** Open Source
- **Platform:** Windows
- **Requires:** Windows 10 / 11
- **File type:** EXE Installer
- **Size:** 205.4 MB
- **Category:** Developer Tools
- **Updated:** 2026-10-25
- **SHA-256:** 4143c37ee9e5312abcf7ccb138f3d959456daf9257ddcb27ae8faee3598d6bb6
- **Canonical page:** https://filecobra.com/app/dotnet-sdk-pc/
- **Download page:** https://filecobra.com/download/dotnet-sdk-pc/
- **Direct download:** https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.100/dotnet-sdk-10.0.100-win-x64.exe

> Microsoft's free open-source SDK for building .NET 10 apps in C#, F# and VB: compiler, dotnet CLI, templates and runtimes included — the developer download.

This is the .NET SDK 10.0.100 (the release-wave SDK for the .NET 10 long-term-support release, supported until November 2028), and the SDK-versus-runtime distinction is the single most common download mistake, so here it is plainly: the .NET Runtime alone only runs already-built .NET programs; the ASP.NET Core Runtime only runs already-built web apps and APIs; the SDK is the developer package that builds them. Installing the SDK gives you everything in one go — the C# 14, F# and Visual Basic compilers, MSBuild, the dotnet command-line tool (dotnet new, build, run, test, publish), NuGet restore, project templates for console, web API, Blazor, worker and test projects — plus the .NET Runtime, ASP.NET Core Runtime and Windows Desktop Runtime it depends on, so a machine with the SDK can both build and run .NET 10 software. End users of your finished app never need the SDK; they install only the runtime, which is a much smaller download. The SDK is MIT-licensed open source, installs side-by-side with older SDKs (8.0, 9.0) without conflict, and a global.json file in a project pins exactly which SDK version that project builds with. It is best for anyone writing C# or F# — desktop, web, cloud, MAUI mobile, games tooling, or command-line utilities. A typical setup: install this SDK, open a terminal, run dotnet new webapi, dotnet run, and you have a working HTTPS API in under a minute, before any IDE is even installed.

## Installation

1. **Download the SDK installer — not the runtime** — Get dotnet-sdk-10.0.100-win-x64.exe from dotnet.microsoft.com under 'Build apps - SDK'. If the page offers you a Runtime or ASP.NET Core Runtime download first, that is the run-only package for servers and end users, not this developer kit.
2. **Run the installer** — Double-click the EXE and click Install. The SDK installs side-by-side with any .NET 8 or 9 SDKs already present; nothing is uninstalled or replaced.
3. **Open a fresh terminal and verify** — Open a new PowerShell or Command Prompt window (existing windows will not see the updated PATH) and run dotnet --list-sdks — you should see 10.0.100 listed, and dotnet --version should report it as the default.
4. **Create and run your first project** — Run dotnet new console -n HelloApp, cd HelloApp, then dotnet run. The SDK restores packages, compiles with C# 14 and executes the app using the runtime it installed.
5. **Pin the SDK per project when needed** — For team or CI work, run dotnet new globaljson in the repo root to create a global.json that pins this SDK version, so every machine and build agent compiles with the same toolchain.

## Editorial verdict

The .NET SDK is one of the most complete single-installer toolchains in mainstream development: one 216 MB download delivers compilers for three languages, a genuinely pleasant CLI, a package manager, test runners and templates for everything from console tools to Blazor web apps, and it coexists peacefully with older SDK versions on the same machine. The .NET 10 LTS line is the right default in 2026 — three years of support, C# 14, and none of the churn of the short-term releases — and side-by-side installs plus global.json pinning make version management boring in the best way.

The persistent problem is naming, not engineering. Microsoft's download pages present SDK, Runtime, ASP.NET Core Runtime and Desktop Runtime side by side, and new developers routinely install a runtime and then wonder why dotnet build does not exist. The SDK is also Windows-installer heavy compared with the scriptable installs on Linux. Judge it as a toolchain, though, and it is exemplary: free, open source, and fast.

### Strengths

- One installer contains the complete toolchain — compilers, MSBuild, the dotnet CLI, NuGet, templates and all three runtimes — so there is no second download before your first program compiles and runs.
- .NET 10 is a long-term-support release backed until November 2028, which makes SDK 10.0.100 a stable target for production work rather than a version you must abandon in eighteen months.
- Multiple SDK versions install side-by-side without conflict, and a global.json file pins each repository to its exact SDK, eliminating works-on-my-machine build differences across a team.
- The dotnet CLI is fully scriptable and identical across Windows, macOS and Linux, so the commands you learn locally transfer unchanged to CI pipelines and containers.
- The SDK is MIT-licensed open source developed in the open on GitHub, with the full source, issue tracker and roadmap public — unusual transparency for a flagship vendor toolchain.

### Trade-offs

- Microsoft's naming invites the classic beginner mistake of installing the Runtime or ASP.NET Core Runtime instead of the SDK, after which no compiler or dotnet build command exists on the machine.
- Each SDK band is a multi-gigabyte on-disk footprint once workloads, targeting packs and NuGet caches accumulate, and keeping 8.0, 9.0 and 10.0 side-by-side multiplies that cost.
- The SDK alone is not an IDE: productive editing still means installing Visual Studio or VS Code with the C# Dev Kit separately, which the download page does not make obvious to newcomers.

## FAQ

**Is .NET SDK for Windows PC free and open source?**

Yes. .NET SDK for Windows PC is completely free and open-source software. You can download and use it at no cost, and its source code is publicly available.

**What is the difference between the .NET SDK and the .NET Runtime?**

The SDK is for building; the Runtime is only for running. The .NET Runtime contains just the execution engine and base libraries needed to launch an already-compiled .NET application — it has no compiler and no dotnet build command. The SDK (this download) contains the compilers, MSBuild, the dotnet CLI and templates, and it also installs the .NET Runtime, the ASP.NET Core Runtime and the Windows Desktop Runtime. Rule of thumb: developers install the SDK; servers and end-user machines install only the runtime that matches the app.

**Can I have multiple .NET SDK versions installed simultaneously?**

Yes — side-by-side installation is a designed feature, not a hack. The 10.0.100 SDK installs alongside 8.0 and 9.0 SDKs without disturbing them, and each project targets the framework it specifies in its .csproj. Add a global.json at a repository root to pin which installed SDK that repo builds with; without one, dotnet commands use the newest SDK present. Run dotnet --list-sdks to see everything installed.

**Should I use global.json for all my projects?**

For anything shared — team repositories, open-source projects, CI builds — yes: global.json guarantees every developer and build agent compiles with the same SDK band and feature version, which prevents a whole class of heisenbugs where a newer SDK quietly changes build behaviour. For throwaway personal experiments it is optional, but creating one costs a single command (dotnet new globaljson), so most experienced .NET developers add it by default.

**Why does `dotnet --version` show a different version than my project?**

Because the two numbers measure different things. dotnet --version reports the SDK that the CLI is using — the newest installed, or the one pinned by global.json in the current folder. Your project's .csproj states a TargetFramework such as net10.0, net9.0 or net8.0, which is the runtime/API level the app is built against. An SDK of 10.0.100 can build projects targeting .NET 8, 9 or 10, so an SDK version higher than the target framework is normal and expected.

**Do I need Visual Studio to write C#?**

No. The SDK plus any editor is a complete C# environment: dotnet new creates projects, dotnet build compiles them and dotnet run executes them, all from the terminal. In practice most developers pair the SDK with Visual Studio (which bundles its own copy of an SDK) or with VS Code plus the free C# Dev Kit extension for IntelliSense and debugging — but those are editing conveniences layered on top of this SDK, not requirements.

---

Source: https://filecobra.com/app/dotnet-sdk-pc/ · Mirrored from the publisher's own release channel by FileCobra. FileCobra runs no antivirus lab of its own.
