ManifestGames.GameplayCSharpBindings

SWIG-generated C# bindings for the gamenetworking gameplay library, packaged as a single NuGet package (ManifestGames.GameplayCSharpBindings) that also carries the native binaries per platform.

Note that this is for consumption by clients (game engine bindings, or bots) - not for servers

Layout

• src/GameplayCSharpBindings/ — SWIG-generated .cs output (committed) + hand-written GameplayCSharpBindings.xml API documentation + package .csproj
• swig/interface.i — snapshot of the SWIG interface definition
• swig/generate.sh — regeneration script (run from the root of the native gamenetworking repo)
• src/GameplayCSharpBindings/runtimes/<rid>/native/ — native libs packed into the NuGet package at runtimes/<rid>/native/ (CI refreshes these from the OCI registry before packing):
  • linux-x64 → libgamenetworking.so (committed; refreshed by CI to the exact Native-OCI tag)
  • android-arm64 → libgamenetworking.so (CI-staged from the OCI registry; built upstream only when the NDK is on the agent — the package ships without Android when absent, with a loud CI warning)

XML API documentation

The NuGet package ships a <PackageId>.xml file alongside the DLL, providing IDE tooltips and dotnet build warnings for every public type and member. The documentation is hand-written (the SWIG output has no doc comments) and staged over the compiler's (empty) generated XML at build time via a post-build target (StageHandWrittenApiDocs in the .csproj).

Consuming

<PackageReference Include="ManifestGames.GameplayCSharpBindings" Version="0.1.1" />

.NET resolves the correct native library from the package's runtimes/ folder automatically (linux-x64 and android-arm64 work out of the box on .NET 6+ and MAUI-style deployments; Unity consumers import the native binary as a plugin themselves).

Releasing

# 1. place native libs in src/GameplayCSharpBindings/runtimes/<rid>/native/
dotnet pack src/GameplayCSharpBindings -c Release -o artifacts
# 2. publish artifacts/*.nupkg to your feed

Keep the NuGet version in lock-step with the native library version — they are ABI-coupled.

CI flow (Jenkins + OCI registry)

1. gamenetworking/Jenkinsfile.client builds the native lib (linux-x64, plus android-arm64 when the NDK is on the agent), pushes the .so files to the in-cluster OCI registry (helm docker-registry, plain HTTP) with oras as <sha12>-linux-x64 / <sha12>-android-arm64 tags, verifies the tags are resolvable, and only then pushes the generated .cs files to this repo as a commit carrying a Native-OCI: gamenetworking/native@<sha12> trailer.
2. A GitHub webhook on this repo (push events → <jenkins>/github-webhook/, githubPush() trigger in this Jenkinsfile) fires the bindings build.
3. This Jenkinsfile parses the Native-OCI trailer from the trigger commit and pulls that exact native tag from the OCI registry into src/GameplayCSharpBindings/runtimes/<rid>/native/ before packing — so a triggered build is guaranteed binaries matching the bindings it builds. linux-x64 is required; android-arm64 is staged when the tag exists (the native build is NDK-gated upstream) and the pack stage warns when it is absent.

Manual runs can override the tag with the OCI_TAG parameter, or build the native lib locally with BUILD_NATIVE=true.