RimWorld 1.7 and .NET

[krafs]

RimWorld 1.7 doesn't run on Unity anymore. It runs on Ludeon's own engine, Waylith, on their own build of .NET 10. That changes what RimRef ships, so I want to explain how and why here, and leave it open for community discussion.

What changed

Up to 1.6, RimRef included every assembly in the game's Managed folder, including mscorlib. So a mod compiled against the exact .NET the game used.

From 1.7, RimRef only includes the game's own assemblies, like Assembly-CSharp and Waylith. You get .NET from the .NET SDK instead, the same way any other .NET project does. Ludeon's .NET only adds some APIs, and doesn't remove anything, so whatever you compile against the SDK will be there in the game.

The main reason is compatibility - mods reference other mods, and shipping Ludeon's .NET would force RimRef onto every mod that depends on that mod.

What we lose

Two things, basically.

We can't publicize .NET itself anymore. The SDK's reference assemblies don't have private members, so publicizing e.g. List<>._items won't work.

We also can't compile against what Ludeon adds to their version of .NET, like the patching- and profiling APIs in the WaylithClr namespace.

Workarounds

We can still get to all of it at runtime.

We can use UnsafeAccessor:

static class MethodBodyUpdaterAccess
{
    [UnsafeAccessor(UnsafeAccessorKind.StaticMethod, Name = "get_IsSupported")]
    public static extern bool IsSupported([UnsafeAccessorType("WaylithClr.MethodBodyUpdater, System.Private.CoreLib")] object? _);
}

Then call MethodBodyUpdaterAccess.IsSupported(null).

Other options

The obvious one is to keep doing what RimRef did up to 1.6, and ship Ludeon's .NET. We'd get everything, and could publicize all of .NET. The problem is that a mod compiled that way references System.Private.CoreLib for every single type, even object. Anyone referencing that mod without the same RimRef setup gets compile errors on every type. So every mod that depends on your mod would need RimRef too, and we'd end up with two kinds of incompatible mod libraries. We'd also lose .NET's docs in the IDE, and source generators like [GeneratedRegex].

Another option is to patch Ludeon's APIs onto copies of the SDK's reference assemblies. We could then call them directly. I've built this, and it works. But it adds complexity to the package generation, and means the package swaps out part of the SDK for everyone on 1.7.
We can move to this approach later without breaking, if the APIs prove worth it to modders.

The cleanest fix would be for Ludeon to ship a small public WaylithClr assembly that forwards to CoreLib. RimRef would just include it like any other game assembly. But that's up to them.

Questions

Do you need Ludeon's APIs or .NET internals at compile time? What for?

Are there approaches I've not considered?