# UnrealCSharp: running C# game logic inside Unreal Engine > UnrealCSharp is a C# programming plugin for Unreal Engine, built on .NET 10 and offered with CoreCLR, Mono or LeanCLR. It generates C# from the engine's reflection data, lets you declare UClass, UInterface, UStruct and UEnum directly in C#, and hot reloads code in the editor. The plugin itself is C++. **crazytuzi/UnrealCSharp** — UnrealCSharp, based on .NET 10 (CoreCLR/Mono/LeanCLR), is a C# programming plugin for UE. - Repository: https://github.com/crazytuzi/UnrealCSharp - Website: https://unrealcsharp.github.io/ - Stars: 808 · Forks: 122 - Language: C++ - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/crazytuzi-unrealcsharp ## A .NET runtime inside the engine process UnrealCSharp is a C# programming plugin for Unreal Engine, and it is based on.NET 10. The runtime is not fixed: the project names CoreCLR, Mono and LeanCLR as the options, and the description states that it provides several programming modes. That is the whole architectural premise. Unreal Engine is a C++ engine, and this plugin embeds a managed runtime so that game logic can be written in C# and compiled by the.NET toolchain, while the engine's own types are exposed to it through generated bindings. The primary language recorded for the repository is C++, which is what you would expect from a plugin that has to live inside the engine as a native module and speak the engine's reflection and object system. The C# side is the payload. For a team deciding whether this is worth the complexity, the question is usually about language fit rather than capability. A studio with.NET libraries, tooling and hire already in C# gets to reuse them. A team that is already fluent in C++ and has its own engine-side framework gets less from it, and pays for a second runtime in the process. The project is MIT licensed, the documentation lives at unrealcsharp.github.io, and the last push to the repository was on 2026-10-22, with the most recent release v1.4.0 from 2026-10-10. ## Bindings generated from the engine's own reflection data The feature list is written in Chinese in the project page, and it is worth translating because the first two items are the mechanism the rest builds on. The first is support for all reflection types, with C# code generated automatically. The second is the ability to statically export various data types and functions. Put together, that means the plugin reads the engine's reflection information and produces C# declarations for the engine's types, so that a C# programmer writes against the same class and function names the engine exposes. This is the part that decides whether the plugin is pleasant to use. A hand-written binding layer for an engine of this size is not a weekend project, and it goes stale with every engine release. Generating from reflection means the bindings track whatever the engine version actually contains, and it means the C# API surface is the engine's API surface rather than a curated subset of it. The cost is the usual one for code generation: the generated API is the engine's API, warts included. There is no place for the plugin to add a nicer abstraction over a rough engine edge, because the abstraction would have to be maintained separately and would then drift from the generated code. The feature list does not claim such an abstraction, and the documentation pages linked from the project cover getting started, dynamic classes, debugging and an FAQ rather than a curated API guide, which is consistent with a design where the engine's own surface is the interface. The engine versions this applies to are given explicitly: Unreal Engine 5.0 through Unreal Engine 5.8. ## Dynamic classes without a Blueprint host The third feature is the one that changes how a team works with content. The project claims a strong dynamic class capability: you can generate UClass, UInterface, UStruct and UEnum directly through C#, and it does so without requiring a Blueprint carrier. In Unreal terms that means the type is declared in code rather than being authored in the editor's Blueprint tooling and then consumed from C#. The trade-off is the mirror image of the benefit. A Blueprint-authored class has an editor surface: a designer can open it, adjust defaults, derive from it, and see it in the asset browser. A class that exists only in C# has none of that. It is faster to create, it is reviewable in a pull request, it version-controls well, and it is not editable by anyone who only works in the editor. For a team that already lives in text, source control and code review, that is a good trade. Unreal's editor-based workflow is one of the more common sources of merge pain in game development, and moving type declarations into C# moves them into the part of the workflow that already has conflict resolution. For a team with designers who own data types and their defaults, it is not. The documentation has a dedicated page on dynamic classes, which suggests the feature is meant to be used deliberately rather than universally, and the getting started page is where a new user would find out how far it is expected to go. ## Hot reload in the editor, hot update through a Pak Two of the listed features address the iteration loop, and they are different mechanisms. In the editor, C# changes can be hot reloaded. The project lists this as hot reloading of C# changes under the editor, alongside what it calls simple and convenient code debugging. The debugging documentation page is separate, which suggests that the debug experience is a supported workflow rather than an accident of the plugin. For shipping, the plugin supports C# hot update through a Pak. That is a different thing: a Pak is the packaged archive format the engine ships content in, so a code update is delivered as part of the package rather than as a rebuild of the executable. For a live service or a game with a downloadable content model, that changes the update cycle for scripts written in C#. It also changes the packaging story, and this is where a team should think carefully. Anything delivered through a Pak becomes part of what the engine loads at runtime, and the platform specific rules for what may be loaded that way differ per console and per store. The project does not document those constraints in its feature list, so the honest position is that the mechanism exists and the platform rules around it are something to confirm per target. The interaction between the two is worth noting too. If code can change in the editor without a restart, the line between a development iteration and a shipped patch gets thin, and a team will want an explicit policy about which changes may be hot updated. ## Five runtime platforms and a fixed engine range The platform support section is short and specific. Runtime platforms are Windows, macOS, Linux, Android and iOS, and engine versions from Unreal Engine 5.0 to Unreal Engine 5.8. Cross-platform support is also listed as a feature in its own right. The engine range is the constraint to plan around. A plugin that binds to the engine's reflection data is tied to the engine version it was generated against, so the 5.0 to 5.8 window is the set of versions you can use without regenerating or waiting for support. When a new engine version ships, the question for your project is whether the plugin supports it, and the release history suggests the project is active on that front: v1.4.0 on 2026-10-10, v1.3.0 on 2026-09-14 and v1.2.0 on 2026-06-03, with the last push on 2026-10-22. On the runtime choice, the project names CoreCLR, Mono and LeanCLR. Each of those has different characteristics around startup cost, memory footprint and platform availability, and the feature list mentions several programming modes, which is presumably how the plugin exposes them. The project page in the excerpt does not state which of them a new project starts with, so that is a question for the getting started documentation rather than something to assume. The community channels are a QQ group and a Discord, and the project links a getting started page, a dynamic classes page, a debugging guide and an FAQ, which is a reasonable documentation shape for a plugin that has to explain both the C# side and the engine binding side. ## What the repository actually contains The top level of the repository tells you the shape of the deliverable, and it is a plugin distribution rather than a library. There is UnrealCSharp.uplugin at the root, which is the descriptor the engine reads to discover a plugin and its modules. Next to it are Source for the native C++ module, Script for the C# side, Template for the scaffolding used when a project is set up, and Resources for assets. That structure is worth understanding because it shows what the plugin has to do. The Script directory is where the managed code and the generation logic live, and the Template directory is what makes the getting started experience possible: a new project needs a C# project wired into the engine's build, and the template provides that wiring rather than leaving the user to work it out. The .gitmodules file at the root indicates that some dependencies arrive as submodules, which is common for engine plugins that pull in a runtime or a generated SDK. For a team evaluating this, the practical next step is not to read the feature list again but to open the getting started page and the FAQ, because the questions that decide adoption are the operational ones. Which runtime is used by default, how the generated code is refreshed when the engine updates, how debugging attaches to a running session, and what has to be configured for a shipping build rather than an editor build. The project links all four kinds of page, and the feature list answers none of them. ## Conclusion UnrealCSharp suits a studio whose programmers are stronger in C# than in C++, or whose existing tooling and libraries are .NET based and would otherwise be unreachable from a game project. It is the wrong choice if you want Unreal's own toolchain with no extra runtime, because the plugin introduces a .NET runtime into the process, and it is the wrong choice if your project targets an engine version outside the 5.0 to 5.8 range. Verify three things before adopting it: that the .NET runtime variant you choose is the one your deployment target can ship, that the dynamic class approach fits how your team wants content authored, since a UClass declared in C# has no Blueprint counterpart to edit, and that the engine version your project pins is inside the supported range on the day you upgrade. ## FAQ ### What is UnrealCSharp? It is a C# programming plugin for Unreal Engine, based on .NET 10 with the runtime options CoreCLR, Mono or LeanCLR. The plugin itself is C++, and the repository describes it as providing several programming modes for game development. ### Which Unreal Engine versions does UnrealCSharp support? The project lists engine versions from Unreal Engine 5.0 to Unreal Engine 5.8, and runtime platforms of Windows, macOS, Linux, Android and iOS. The most recent release is v1.4.0 from 2026-10-10. ### How does UnrealCSharp expose engine types to C#? It supports all the reflection types and generates the C# code automatically, and it can statically export the various data types and functions. The generated bindings therefore track what the engine version actually contains rather than a hand written layer. ### What is the dynamic class feature in UnrealCSharp? You can generate UClass, UInterface, UStruct and UEnum directly from C#, and the project states this does not need a Blueprint carrier. The trade-off is that such a type has no editor surface, so it cannot be adjusted in the Blueprint editor the way an authored class can. ### Can I hot reload C# code in UnrealCSharp? Yes, in the editor C# changes can be hot reloaded, and the project lists simple and convenient code debugging as a feature with its own documentation page. For shipping, C# hot update through a Pak is supported, which delivers code changes inside the packaged archive rather than through an executable rebuild. ### What licence does UnrealCSharp use? The project is MIT licensed, with the licence file at the root of the repository. The project also links a getting started page, a dynamic classes page, a debugging guide and an FAQ in its documentation site, plus a QQ group and a Discord for community support. ## Sources - [crazytuzi/UnrealCSharp on GitHub](https://github.com/crazytuzi/UnrealCSharp) - [License: MIT](https://github.com/crazytuzi/UnrealCSharp/blob/main/LICENSE) - [Project website](https://unrealcsharp.github.io/) - [README](https://github.com/crazytuzi/UnrealCSharp/blob/main/README.md) - [Releases](https://github.com/crazytuzi/UnrealCSharp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crazytuzi-unrealcsharp