UnrealSharp: C# and Hot Reload for Unreal Engine 5

What UnrealSharp Changes for Unreal Engine Game Code

UnrealSharp is an open-source Unreal Engine 5 plugin that lets developers write game code in C# on .NET 10. It is intended primarily for teams that prefer the C# language and NuGet ecosystem but need to work inside Unreal Engine rather than as a standalone engine or generic .NET game framework. The README lists Actors, ActorComponents, and other reflected Unreal types as C# development targets. Pure Blueprint projects can work, but the README strongly recommends starting from a C++ project because that makes project support easier.

The plugin does not replace Unreal Engine or provide a separate rendering and gameplay stack. Its role is the managed code layer between C# and Unreal's reflected API. A C# type can derive from a generated Unreal class, while attributes such as `UClass`, `UProperty`, and `UFunction` connect managed declarations to the engine's reflection model. The README also says the C# API is generated from reflected C++ code across the engine, its plugins, and the developer's own project. This is the central reason to assess the plugin's generated API against a real workflow rather than treating it as a conventional Unity C# setup.

NuGet packages are available through the normal .NET ecosystem, which makes UnrealSharp more relevant to developers who already manage C# dependencies. It does not, however, imply that arbitrary managed libraries will map cleanly to Unreal types. Native assets, engine objects, replication, delegates, and reflected members still have to follow the binding conventions shown by the project.

Generated Unreal API and C# Reflection Binding

Based on the repository layout, UnrealSharp consists of managed code, native Unreal plugin code, build properties, resources, configuration, and project templates. That structure is consistent with a bridge that participates in Unreal's build process rather than a single C# library. Relevant top-level files include `Managed/`, `Source/`, `Build/`, `Templates/`, `UnrealSharp.uplugin`, and several `.props` files that contain UnrealSharp-specific build settings.

The documented binding flow starts with Unreal's reflected C++ code. UnrealSharp generates the corresponding C# API, including engine types, plugin types, and project-owned types. Developers can then derive from a `UClass` and declare reflected properties and functions with UnrealSharp attributes. The sample `AResourceBase` class demonstrates this model. It derives from `AActor`, marks components and replicated state with `UProperty`, and exposes interaction and respawn logic through `UFunction` methods.

Replication is integrated into the declaration model. The sample combines `PropertyFlags.ReplicatedUsing` with `OnRep_IsPickedUp`, while a multicast delegate is declared through `TMulticastDelegate`. This matters because UnrealSharp is handling engine concepts such as property replication, Blueprint events, timers, Niagara effects, and component ownership. Adoption therefore requires familiarity with Unreal behavior even when the implementation language is C#. A developer moving from a pure C# engine cannot assume that ordinary property assignment is the only consideration.

Editor Hot Reload and the .NET 10 Development Loop

The feature with the clearest effect on iteration is C# hot reload. According to the README, developers can recompile and reload C# code without restarting the editor. For gameplay programming, that removes at least one restart boundary from the usual edit, compile, load, and repeat cycle. The repository does not document which kinds of C# changes are reloadable, whether every schema change is supported, or how state is preserved, so those behaviors should not be assumed.

The workflow still depends on generated Unreal bindings and the plugin's integration with Unreal Engine. The prerequisite versions are Unreal Engine 5.6, 5.7, or 5.8 and .NET 10.0.5 or newer. The `UnrealSharp.Build.props`, `UnrealSharp.AOT.props`, `UnrealSharp.Automation.props`, and `UnrealSharp.Shared.props` files indicate separate build, ahead-of-time, automation, and shared configuration concerns. Their names show that the plugin has more than one build context, although the README does not explain when each property file applies.

A careful adoption test should distinguish source-level gameplay changes from structural Unreal changes. Recompiling a method is not the same operation as adding a reflected property, changing replication metadata, or altering a component hierarchy. The documentation explicitly promises C# hot reload, but it does not promise a specific list of safe or unsafe changes. That distinction is especially relevant for teams whose iteration time depends on changing gameplay classes repeatedly.

Installing UnrealSharp Through the Official Quickstart

The README does not provide installation commands, so none should be inferred. It directs new users to the official Get Started page at `https://www.unrealsharp.com/getting-started/quickstart`. Before following that page, verify that the workstation has a supported Unreal Engine version, .NET 10.0.5 or newer, and preferably a C++ Unreal project. Windows and macOS are supported. Linux, iOS, and Android are listed as planned, not supported.

For a first real use, the documented example is the C# `AResourceBase` Actor shown in the README. It creates a replicated, interactable resource with a static mesh, health component, pickup amount, respawn timer, Niagara effect, multicast event, and Blueprint-overridable visibility behavior. After obtaining the project setup from the quickstart, a developer can use that example to inspect how an Actor is declared and how its engine-facing members are annotated. The repository does not state the exact menu path, project-creation command, or editor button used to install or initialize the plugin.

The sample's flow is concrete. `GatherResource` checks `bIsPickedUp`, attempts to add the item to the player's inventory, awards experience, starts a timer, updates the replicated state, and invokes `OnRep_IsPickedUp`. `OnRespawned` clears the state and runs the same notification path. That example is a better compatibility check than a class with no engine interaction because it covers components, replication, delegates, timers, Niagara, and Blueprint events.

Sample Defense Game, Slime Guzzler, and Cropout Scope

UnrealSharp's README links several projects that demonstrate use beyond a minimal code sample. These include `UnrealSharp-SampleDefenseGame`, built for Mini Jam 174, `Epic-MegaJam-Project`, identified as an Epic MegaJam 2025 entry, and `UnrealSharp-Cropout`, which is described as an Unreal Engine sample ported from Blueprints to C#. These links indicate relevant examples for prospective users, but the README does not describe their architecture, dependencies, build settings, or production readiness.

The Cropout example is relevant when evaluating mixed workflows because its stated origin is a Blueprint sample converted to C#. The `AResourceBase` example similarly leaves a hook for Blueprint behavior through `FunctionFlags.BlueprintEvent` and calls `OnIsPickedUpChanged`. UnrealSharp therefore supports a boundary between managed code and Blueprint-extended behavior instead of requiring every feature to remain in one language. Teams can judge whether that boundary fits their intended division of responsibilities.

The linked games and samples should not be treated as proof of compatibility for every platform or workflow. The README does not state which supported platform each sample was built on, whether all samples use the latest Unreal Engine and .NET versions, or whether their dependencies are included in a reproducible package. They are useful references for reading code and asking maintainers about migration questions, but the repository's quickstart and sample classes remain the better first verification targets.

Platform, License, and Release Boundaries

Platform support is the clearest adoption boundary. Windows and macOS are marked supported. Linux, iOS, and Android are marked planned. A team targeting one of those three platforms should treat UnrealSharp as unsuitable for production adoption at present, regardless of its C# API or hot reload feature. A Windows or macOS team should still confirm that every required deployment target is covered by its own CI and packaging process, because the README provides no target-specific deployment instructions.

The repository uses the MIT license, which permits broad use, modification, and redistribution under that license's conditions. This is a licensing statement, not legal advice. Teams distributing a game built with the plugin should review the applicable license text and dependency licenses themselves rather than assuming that the project's MIT status settles every distribution question.

The repository is not archived, and its last push was on 2026-10-11. However, it has no GitHub releases. That means the repository history shows recent code activity, while the project documentation does not define a stable release channel, compatibility matrix across plugin versions, or formal upgrade procedure. Pinning and upgrading UnrealSharp therefore requires repository-specific care. Unreal Engine 5.6 through 5.8 are listed as supported, but there is no documented migration guide for moving between those editor versions or between plugin commits.

UnrealSharp Compared with Native Unreal C++ and Blueprints

The practical alternative is Unreal Engine's native C++ and Blueprint workflow. Native C++ works directly with Unreal's reflected types and build system, but it does not provide the C# language or NuGet package access documented for UnrealSharp. Blueprints provide an editor-oriented visual programming model and integrate with Unreal concepts such as components and events. Neither alternative is described as offering UnrealSharp's specific C# hot reload feature, because the README makes no such claim.

UnrealSharp changes the implementation language and places .NET 10 beside Unreal's reflected C++ surface. Native C++ keeps the entire engine interaction in the engine's established implementation environment. Blueprints move much of the authoring process into graph-based editor tools rather than managed source files. The choice therefore involves more than syntax preferences. It includes .NET dependencies, generated bindings, editor reload behavior, platform targets, and the division between C#, Blueprint, and C++.

A team that already has Unreal C++ expertise or requires an unlisted platform has a narrower case for adopting this plugin. A C# team targeting Windows or macOS, particularly one that already depends on NuGet packages, has a stronger reason to test it. The sample's Blueprint extension point also makes mixed-language design possible, but the repository does not document a general migration process from an existing Blueprint or C++ game.

Editorial conclusion

C# teams working on Windows or macOS should evaluate UnrealSharp against a small Actor or ActorComponent, including generated bindings, NuGet access, and an actual hot reload cycle. Projects that require Linux, iOS, or Android support, or that need a formally defined upgrade path without GitHub releases, should not adopt it yet. The first verification point is whether the plugin supports the project's exact Unreal Engine version and target platform.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. UnrealSharp/UnrealSharp on GitHub