# UnityCsReference: What Unity's C# Reference Source Actually Lets You Do

> UnityCsReference is the C# half of the Unity engine and editor, published read-only under the Unity Reference Only License. It is a reading resource for engine behaviour, not a fork you can ship.

**Unity-Technologies/UnityCsReference** — Unity C# reference source code.

- Repository: https://github.com/Unity-Technologies/UnityCsReference
- Stars: 13,011 · Forks: 2,557
- Language: C#
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/unity-technologies-unitycsreference

## What UnityCsReference Is For, and Who Should Read It

UnityCsReference is the C# portion of the Unity engine and editor source code, published on GitHub by Unity Technologies. The README describes it as being for reference purposes only. That single sentence defines the audience. This is not a library you add to a project, not a patch set, and not an SDK. It is the actual C# that ships inside Unity, laid out so you can read it.

The people who get value from it are the ones hitting a wall in the documented API surface. If a serialization attribute behaves unexpectedly, if a coroutine stops after an object is disabled, if an editor callback fires in an order you did not predict, the reference source is where the answer lives. Reading the implementation settles arguments that documentation and forum posts cannot. The second group is tooling authors: people writing editor extensions, source generators or analyzers who need to know the exact shape of a type rather than the shape the manual implies. The third group is the curious: engineers who want to know how a large C# codebase is organised before they write their own.

It is not for anyone who wants to change engine behaviour. The README is explicit that the terms of use do not permit modifying or redistributing the C# code in either source or binary form, and directs anyone who wants to modify Unity's source (C# and C++) to contact Unity sales for a commercial source code license. That is a different product with a different price.

## How the Repository Is Laid Out and Why the Paths Move

The top level contains Editor/, External/, Modules/, Projects/, Runtime/, Tools/, artifacts/, LICENSE.md, README.md and third-party-notices.txt. That split is not arbitrary. Runtime/ holds the player-side code, the part that ends up in a built game. Editor/ holds the code that only exists inside the Unity Editor, which is why editor-only APIs are unavailable at runtime and why a build can fail on a file that compiles fine in the editor. Modules/ groups engine subsystems. External/ covers dependencies, and the README notes that the repository includes third-party code subject to the notices in third-party-notices.txt, so not every file you open is Unity's own.

The C# solution lives at Projects/CSharp/UnityReferenceSource.sln. Opening that solution is the intended way to browse the code with working navigation rather than grepping file by file.

The important constraint is stated plainly in the README: the folder and file layout of the reference source matches the Unity source tree layout, and it can and will change between different Unity versions. That means a path you memorised for one release may not exist in the next. Any link you save, any script that assumes a directory, any note that says "look in this folder" has an expiry date tied to the Unity version. Treat paths as version-scoped, not as a stable interface. This is the single most common way people get burned by the repository, and it is not a bug. It is the consequence of publishing a mirror of an internal tree.

## Getting the Source and Reading Your First Real Question

There is nothing to install. The repository is source code for reading, and there is no package, no build step described in the README, and no runtime component to add. You clone it and open the solution.

The clone is a plain git operation against the default branch, master.

```bash
git clone https://github.com/Unity-Technologies/UnityCsReference.git
cd UnityCsReference
```

After the clone finishes you have the full tree, including the Editor/, Runtime/ and Modules/ directories and the third-party-notices.txt file. There is no dependency restore step in the README, because the README does not present this as a buildable product.

The README points at the solution file for browsing. If you have a .NET toolchain and an editor that opens solution files, this is the path to use:

```bash
ls Projects/CSharp/UnityReferenceSource.sln
```

That command should print the path, confirming the solution exists in your checkout. Opening it gives you project structure and go-to-definition across the C# code, which is far more useful than reading individual files in a browser tab.

A realistic first use is answering one narrow question. Pick a type you already call in your game, find it in Runtime/ or Editor/ depending on where it is available, and read the method you depend on. You are looking for the branch you did not expect: the null check that returns early, the condition that skips a callback, the order in which two things happen. That is the kind of detail the reference source gives you and the manual usually does not.

## The Licence Is the Limitation

Most of the friction with UnityCsReference is legal rather than technical, and the README does not soften it. The terms of use permit reference use only. You may not modify or redistribute the C# code in source or binary form. The repository also states that pull requests are not accepted, so the normal open source contribution loop is closed by design. If you find a bug, the README asks you to file it with the Unity Bug Reporter rather than open a pull request.

The licence is listed as NOASSERTION in the repository metadata, which means the automated classifier could not map it to a standard SPDX identifier. The actual terms are in LICENSE.md and point to the Unity Reference Only License. Read that file rather than assuming it behaves like MIT or Apache-2.0, because it does not. There is no grant to ship a modified engine, and no grant to vendor the code into your own product.

A second limitation is practical. Because the tree mirrors an internal layout that changes between Unity versions, there is no compatibility promise across releases. Code you read in one version may be restructured, moved or removed in the next, and the README says so directly. If your workflow depends on a specific path, you own the job of re-checking it after every Unity upgrade.

The third limitation is scope. This is the C# part only. Anything implemented in C++ is not here. When a method is a thin wrapper over native code, reading the C# tells you the signature and the managed-side checks, not the behaviour underneath. For those cases the reference source answers half the question, and you should expect that before you start digging.

## UnityCsReference Versus Decompiling the Assemblies

The obvious alternative is a decompiler. Tools that open the managed assemblies shipped with a Unity installation give you broadly the same C# in an IDE, without cloning anything, and they work against the exact build you have installed rather than a repository snapshot.

The difference in approach matters. A decompiler reconstructs source from compiled IL. You get something close to the original, but local variable names, comments, compiler-generated constructs and formatting are not guaranteed to survive the round trip, and the output can be harder to read in exactly the places where the logic is subtle. UnityCsReference is the source Unity publishes, organised into the same directories as the engine tree, with the solution file provided for navigation. It reads the way the engine team wrote it.

The trade-off runs the other way too. A decompiler always matches your installed editor version, because it reads your installed binaries. The repository is a published snapshot, and its layout can and will change between Unity versions. If you are chasing a bug in a specific editor build and you need certainty that the code you are reading is the code that is running, the decompiler is the more direct route. If you want readable, navigable source and you are willing to confirm the version, the repository is better.

There is also the licence question. Decompiling Unity's assemblies is governed by the terms you accepted for the Unity Editor. Reading the reference source is governed by the Unity Reference Only License. They are different documents, and neither one grants you the right to redistribute what you read.

## Maintenance, Versioning and What an Upgrade Costs You

The repository is not archived, and the last push was on 2026-09-18. The README's heading names Unity 6000.7.0b1 as the version this C# reference source corresponds to, which tells you the publication tracks Unity releases rather than running as an independent project. There are no releases published on the repository, so there is no changelog to follow and no tagged version to pin against. The commit history on master is the record.

That shapes the upgrade cost. Nothing breaks in your project when this repository changes, because you do not depend on it at build time. What breaks is your own notes, links and scripts. The README states that the layout matches the Unity source tree and can change between Unity versions, so the maintenance burden is entirely on the reading side: re-locating files after a Unity upgrade, re-checking that the method you studied still has the same branches.

For teams, the sensible pattern is to record the Unity version alongside any note you take from this code. A note that says "this method returns early when X" is worth much less than one that says which Unity version it was read from. That is not process advice for its own sake; it is the direct consequence of a repository that mirrors a moving internal tree and publishes no releases.

On licence implications, the README is clear enough that no interpretation is needed: reference purposes only, no modification, no redistribution, no pull requests, and a commercial source code license available through Unity sales if you need to change the engine. What that means for your specific product is a question for your own legal review, not for this article.

## Conclusion

Adopt UnityCsReference as a reading tool if you need to confirm what a Unity API does before you design around it, and accept that your only output is understanding. Do not treat it as a fork base or a way to patch the engine: the licence forbids modifying or redistributing the C# code in source or binary form, and the README states that pull requests are not accepted. Before you rely on a file path, verify the folder and file layout against your own Unity version, because the README says the layout matches the Unity source tree and can change between versions.

## FAQ

### Is Unity still good in 2026?

The repository makes no claim about Unity's standing as a product. What it shows is that Unity continues to publish the C# reference source: the last push was on 2026-09-18, and the README heading names Unity 6000.7.0b1 as the version it corresponds to.

### Which is better for Unity, C# or C++?

The README does not compare the two languages. It does state that this repository is the C# part of the Unity engine and editor source code, and that a commercial source code license covers both the C# and C++ code if you want to modify Unity's source.

### Is anyone still using Unity?

The repository contains no usage or adoption data, so it cannot answer this. It does show that Unity published a C# reference source corresponding to Unity 6000.7.0b1, with the last push on 2026-09-18.

### Which C# version is Unity compatible with?

The README does not state a C# language version. It only identifies the repository as the C# part of the Unity engine and editor source code and names Unity 6000.7.0b1 as the version it corresponds to.

## Sources

- [Issues](https://github.com/Unity-Technologies/UnityCsReference/issues)
- [README](https://github.com/Unity-Technologies/UnityCsReference/blob/master/README.md)
- [Unity-Technologies/UnityCsReference on GitHub](https://github.com/Unity-Technologies/UnityCsReference)

---

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