Gateway module versioning and --noVersioning
Hosted-module versioning is separate from the version on a generated Caller package. Gateway decides whether each publication of a Receiver surface is versioned.
Default behavior
After CLI and environment parsing:
- Without
--projectKeyorGC_PROJECT_KEY, Gateway runs in standalone mode and disables versioning by default. --keepVersioning(defaulttrue) can re-enable versioning even without a project key.--noVersioningexplicitly disables versioning regardless of project key.
A portal project key ties publication to stable project metadata and is the normal production path.
When to bump Caller package versions
Bump the generated package version shown in Vision when the callable surface changes in a way that affects Callers: renamed members, signature changes, removed types, or unsupported type introduction. See Update a Receiver contract and Contract evolution.
Additive methods are safer but are not guaranteed compatible in every target language. Always regenerate, reinstall, and smoke-test each Caller ecosystem.
When to use --noVersioning
Use --noVersioning for local experiments where you do not want Gateway to track module versions, or
when a deployment policy requires a single unversioned hosted surface.
Do not use it to avoid republishing after a breaking contract change. Callers still depend on the generated package version you install.
Examples
Disable versioning:
dotnet build ./Pricing/Pricing.csprojgg ./Pricing/bin/Debug/net9.0/Pricing.dll --noVersioning
dotnet build ./Pricing/Pricing.csprojgg ./Pricing/bin/Debug/net9.0/Pricing.dll
gg ./Pricing/bin/Debug/net9.0/Pricing.dll --keepVersioning
With a project key (store the key in a secret, not in source):
export GC_PROJECT_KEY="dev:<jwt-from-portal>"gg ./Pricing/bin/Debug/net9.0/Pricing.dll
After startup, confirm discovery and publication in Gateway logs and Vision. If Callers install an old package while the hosted surface changed, failures appear at invocation time—not as an automatic drift rejection unless your deployment verifies versions.
Current limitation: automatic rejection of a changed callable surface published under the same version is not guaranteed. Verify versioning in your deployment.