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

Versions are derived by svu from gamenetworking's conventional commits: nupkg version == OCI native tag == gamenetworking git tag (ADR: docs/adr/0001-svu-for-semantic-versioning.md in the enettest superproject).

Manual escape hatches:

• gamenetworking client job: FORCE_VERSION=vX.Y.Z pins the derived version; NATIVE_TAG overrides the OCI tag.
• this job: VERSION overrides the pack version (empty = csproj pin), OCI_TAG overrides the pulled native tag.

CI flow (Jenkins + OCI registry)

1. gamenetworking/Jenkinsfile.client — Derive release version computes vX.Y.Z (svu); builds; Prepare bindings release stages the generated .cs and the built linux-x64 .so into a clone of this repo; when either differs it pushes the natives to the OCI registry as vX.Y.Z-<lib>-<rid> (non-release builds keep <sha12>-<lib>-<rid> plus the latest-* alias), writes vX.Y.Z into the csproj, commits with a Native-OCI: gamenetworking/native@vX.Y.Z trailer, and tags gamenetworking.
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, pulls that exact native tag ($TAG-client-linux-x64, plus the android tag when it exists) from the OCI registry into src/GameplayCSharpBindings/runtimes/<rid>/native/ before packing — so a triggered build is guaranteed binaries matching the bindings it builds — then packs with the csproj version and dotnet nuget push --skip-duplicate to BaGet.
4. The superproject GitHub Actions workflow only packs for PR validation; its package carries no natives and must never publish (its publish job was removed — see the ADR).

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