# CsWinRT projects Windows Runtime APIs into C# without compiler support

> C#/WinRT is Microsoft's language projection that lets C# consume Windows Runtime APIs by generating C# source from winmd metadata and compiling it into interop assemblies, so neither the C# compiler nor the .NET runtime needs to know about WinRT. It suits teams building Windows apps against WinUI 3 or any other WinRT component, and it is a Windows-only path inside a cross-platform runtime.

**microsoft/CsWinRT** — C# language projection for the Windows Runtime

- Repository: https://github.com/microsoft/CsWinRT
- Stars: 668 · Forks: 135
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-cswinrt

## A projection is an adapter between two type systems

The concept the project rests on is the projection, defined in the README as an adapter that enables programming the WinRT APIs in a natural and familiar way for the target language. C#/WinRT is the C# instance of that idea. It hides the details of interop between C# and WinRT interfaces, and it provides mappings of many WinRT types to appropriate .NET equivalents, with strings, URIs, common value types and generic collections named in the documentation. What the reader should take away is that this is not a wrapper library someone wrote by hand for a few popular APIs. It is a systematic translation layer, generated from metadata, so that the C# surface you write against is the C# shape you expect rather than the shape WinRT happens to use. The people who need it are C# developers calling into Windows components, which today means mostly WinUI 3 and the rest of the Windows App SDK.

## Code generation from winmd is what removes the compiler dependency

The mechanism is metadata driven. WinRT APIs are defined in winmd format, and C#/WinRT includes tooling that generates C# code for consumption scenarios, or generates a winmd for authoring scenarios. The generated C# source is then compiled into interop assemblies, and the documentation compares this to how C++/WinRT generates headers for the C++ language projection. The consequence, stated in the README, is that neither the C# compiler nor the .NET Runtime require built-in knowledge of WinRT any longer. That is the whole point of the project. Earlier versions of .NET Framework and .NET Core had WinRT knowledge baked in, and lifting that out into a separate projection is what the project calls supporting the effort to make .NET more efficient from .NET 5 onwards. The authoring direction, generating a winmd, is the one that matters if you are the producer of a WinRT component rather than the consumer.

## WinRT.Runtime.dll carries activation, marshaling and COM lifetime

There is one assembly every other C#/WinRT assembly depends on. The runtime assembly, WinRT.Runtime.dll, is required by all C#/WinRT assemblies, and it provides an abstraction layer over the .NET runtime supporting .NET 5 and above. It implements several features for all projected C#/WinRT types, and the documentation names three: WinRT activation, marshaling logic, and COM wrapper lifetime management. Activation is the part that surprises newcomers, because instantiating a projected WinRT class is not a constructor call, it is a request that has to be routed through the platform. Marshaling is the conversion of data across the WinRT and .NET representations, and the COM wrapper lifetime management is the part that decides when the runtime's knowledge of a native object ends, which is exactly the area where interop code usually leaks or crashes. The runtime assembly is therefore a shared dependency, not an implementation detail, and its version has to match the projections you consume.

## WinUI 3 is the reason the project exists, but it is not the only user

The documentation is candid about the immediate driver. WinUI 3 is the effort to lift official native Microsoft UI controls and features out of the operating system, so developers can use the latest controls and visuals on any in-market version of the OS, and C#/WinRT is needed to support the changes required for lifting the XAML APIs out of Windows.UI.XAML and into Microsoft.UI.XAML. The scoping is broader than that, though. The project says it is a general effort intended to support other scenarios and versions of the .NET runtime, that the focus is on .NET 5, and that the aspiration is to generate projections compatible down to .NET Standard 2.0, with a pointer to the issues backlog for more information. So WinUI 3 is the reason it was built and the reason it is maintained, and any other WinRT component is a legitimate secondary use.

## Getting the projection: the NuGet package or a build from source

There is no install command in the repository, and the documentation points to the source of the package rather than to a script. The C#/WinRT NuGet package is downloaded from nuget.org, at the Microsoft.Windows.CsWinRT package, and the README also says you can build a C#/WinRT package yourself from source, pointing to the Contributor's Guide for the steps on building the repository. Four documentation files are linked for deeper reading. The usage guide, docs/usage.md, is the developer-facing one. The nuget readme documents how to customise the NuGet package properties, which matters if you publish a package that carries projections. The repository structure document gives a detailed breakdown of the repository, and the COM interop guide is for recommendations on migrating away from System.Runtime.InteropServices, which is the clearest signal of the intended audience. A walkthrough site is also referenced at aka.ms/cswinrt.

## Versioning runs on the .NET SDK monthly cadence

The release section describes a versioning model that surprises people who expect a tool to be versioned independently. Runtime and Windows SDK projection updates typically become available in a future .NET SDK update, which follows a monthly release cadence, and the release notes are said to cover the latest C#/WinRT releases together with the corresponding .NET SDK versions. Updates to the C#/WinRT tool itself are shipped separately through the C#/WinRT NuGet package, and details on breaking changes and specific issues are found in the release notes. So there are two moving parts. The projection you consume follows the .NET SDK, which means your .NET SDK choice determines which WinRT APIs are available to you, and the tool that generates projections moves on its own schedule through NuGet. The release list in the repository reflects this, with a stable 2.3.1 release in July 2026, a 3.0.0 preview in March 2026 and a 2.3.0 prerelease in November 2025. If you need a specific WinRT API, the answer is usually to move the .NET SDK version rather than to hunt for a tool update.

## Where the projection is the wrong tool

The first wrong case is a plain COM component. The documentation ships a COM interop guide with recommendations on migrating from System.Runtime.InteropServices, which tells you the .NET native interop stack is the more direct answer when all you need is to call a COM object. WinRT projection is for a specific ABI with metadata, activation and a lifetime model that the general interop stack does not model for you. The second wrong case is a cross-platform application that only incidentally touches a Windows API on one platform, since the project states that its mission is not to support cross-platform execution directly but to support the cross-platform goals of .NET Core, and every projected assembly drags in the Windows specific machinery. The third is a team that wants to publish its own WinRT component, because the authoring path generates a winmd and carries its own versioning and packaging obligations, and the documentation is thin on the details of that workflow compared with the consumption path. The fourth is a project with a strict release cadence that cannot absorb a monthly .NET SDK upgrade cycle, since the projection you want arrives with the SDK rather than on demand.

## How CsWinRT sits next to C++/WinRT and Rust/WinRT

The related projects section shows the shape of the family. C#/WinRT is part of the xlang family of projects that help developers create APIs that can run on multiple platforms and be used with a variety of languages, and it is also part of the Windows App SDK, the set of libraries, frameworks, components and tools for accessing platform functionality across many versions of Windows. The Windows App SDK is where C++/WinRT, Rust/WinRT, WinUI and WebView2 all live, so the real difference between the projections is the language they target and the ecosystem that consumes them. C++/WinRT generates headers and is the natural fit for a native component, Rust/WinRT covers the Rust side, and C#/WinRT covers the managed side where the calling code is C# and the runtime is .NET. A team with a mixed native and managed codebase can end up with more than one projection in the same product, which is workable but means the activation and lifetime rules have to be understood twice.

## Conclusion

Teams building C# applications that call Windows Runtime APIs, especially WinUI 3 and other Windows App SDK components, are the people CsWinRT serves, and the fact that the projection lives in generated code rather than in the compiler or the runtime is what lets the same .NET runtime target platforms where WinRT does not exist. It is the wrong choice for a team that only needs to talk to a COM component from C#, since the COM interop guide in the documentation points at System.Runtime.InteropServices for exactly that case, and it is the wrong choice for a project that expects cross-platform execution, because the project states plainly that its mission is not to support cross-platform execution directly. Check three things before you adopt it: that your Windows SDK and .NET SDK versions line up with the projection versions you need, since runtime and SDK projection updates land in a future .NET SDK update on a monthly cadence, and that you can live with the monthly upgrade cycle of the SDK rather than pinning a projection, and that your build does not need the winmd authoring path at all, since that half of the tooling only matters if you are shipping a WinRT component yourself. The licence is MIT, the newest stable release is 2.3.1 from 2026-07-23, and the last push was on 2026-10-20.

## FAQ

### What does CsWinRT actually generate?

C# source code for consumption scenarios, or a winmd for authoring scenarios, from the winmd metadata that defines WinRT APIs. The generated C# is compiled into interop assemblies, in the same way C++/WinRT generates headers for the C++ projection.

### Where do I get the C#/WinRT package?

The NuGet package Microsoft.Windows.CsWinRT is downloaded from nuget.org, and the README also says you can build a C#/WinRT package from source, with the steps in the Contributor's Guide.

### What is WinRT.Runtime.dll for?

It is the runtime assembly required by all C#/WinRT assemblies, providing an abstraction layer over the .NET runtime with support for .NET 5 and above. It implements WinRT activation, marshaling logic and COM wrapper lifetime management for all projected types.

### How do C#/WinRT versions relate to .NET SDK versions?

Runtime and Windows SDK projection updates typically become available in a future .NET SDK update, which follows a monthly release cadence, and the release notes list the C#/WinRT releases with their corresponding .NET SDK versions. The C#/WinRT tool itself is updated separately through the NuGet package.

### Is C#/WinRT only for WinUI 3?

WinUI 3 is the reason it was built, since lifting the XAML APIs into Microsoft.UI.XAML required it, but the project says it is a general effort supporting other scenarios and .NET runtime versions, with the aspiration of generating projections compatible down to .NET Standard 2.0.

## Sources

- [Issues](https://github.com/microsoft/CsWinRT/issues)
- [License: MIT](https://github.com/microsoft/CsWinRT/blob/master/LICENSE)
- [microsoft/CsWinRT on GitHub](https://github.com/microsoft/CsWinRT)
- [README](https://github.com/microsoft/CsWinRT/blob/master/README.md)
- [Releases](https://github.com/microsoft/CsWinRT/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-cswinrt