google-cloud-dotnet ships one NuGet package per service, generated from the API definitions

A package per service, and the table is the product

The repository is the Google Cloud Client Libraries for .NET, described as .NET idiomatic client libraries for Google Cloud Platform services, and the README is mostly a catalogue. The available APIs table lists a package name, the latest version pulled from a NuGet badge, and a one line description with a link to the service documentation.

The spread of the catalogue is the first thing to notice. It is not only Google Cloud products. There are Google Ads packages such as Google.Ads.AdManager.V1 and Google.Ads.DataManager.V1, Google Analytics packages for the admin and data APIs, Google Workspace packages for Chat, Meet, Apps Script types and Calendar, plus the long tail of Google.Cloud services: AccessApproval, AdvisoryNotifications, AgentRegistry, AlloyDB, and many more.

So the repository serves two audiences at once. A developer calling Cloud Storage or Cloud Build wants a client for that service only, and a developer building a Google Workspace add-on wants the Chat and Meet clients, which are not cloud infrastructure at all but are published from the same pipeline.

The naming carries the API version rather than the package version. A V1 client is the stable surface, V1Beta and V1Alpha are previews of a surface that is still changing, and the suffix is part of the package name, so Google.Cloud.AlloyDb.V1 and Google.Cloud.AlloyDb.V1Beta are separate packages with separate release lines.

For a team choosing a dependency, that table is the whole decision. The question is not whether to use Google Cloud from .NET, it is which service, which API version, and how mature that client is today.

The code is produced by a generator, so hand edits are lost

The repository layout makes the production model clear. There is an apis/ directory holding the client code, a generator-input/ directory, a Dockerfile.generator, and two shell scripts named generateapis.sh and generateprojects.sh. There is also a cloudbuild-generator-exitgate.yaml, which is a Cloud Build configuration for a gate on the generator pipeline.

Read together, that is a code generation setup: the API surface is derived from definitions, the projects are laid out from that, and a build pipeline enforces the result. The corollary for a consumer is the important part. If you need to change a client, you do not change the file under apis/, because the next generation run will overwrite it. The change belongs in the generator input, or in the generator itself, which is a different kind of contribution from the one most people expect to make.

The.config/ directory, the Directory.Packages.props file, the global.json file and the nuget.config file are the build infrastructure, and Directory.Packages.props in particular is central package management: one file pinning the versions of the shared dependencies that every client package uses, so that the packages in the same repository do not each drag in a different version of the same library. For a consumer that resolves one or two of those packages, that consistency shows up as a small dependency graph, which is one of the real reasons to prefer a per-service package over a bundled one.

The third_party/ directory exists for the code that is not Google's own, and the separation is the kind of detail that matters when a repository ships this many packages under one licence.

The shell scripts are the release process

The root directory of the repository is a list of scripts, and reading their names explains how a change becomes a published package.

build.sh is the entry point, and prepare-release.sh is the one that matters to a consumer, because a release is a multi-package operation and the script encodes the order things have to happen in. checkpackages.sh validates the packages, and checkcompatibility.sh checks compatibility, which for a repository that ships this many client packages is a real concern: a shared dependency moving under a client is exactly the kind of break that needs catching before publication rather than after.

detect-pr-changes.sh inspects a pull request to work out which packages it touches, which is what allows a change to one service to publish only that service's package. The test entry points are runintegrationtests.sh and run-container-tests.sh, and updateconformancetests.sh keeps the conformance test data in step with the API definitions. uploaddocs.sh publishes the API documentation, clean.sh and cleantestdata.sh and processbuildtiminglog.sh handle housekeeping and build telemetry, and toolversions.sh pins the tool versions used by the build.

The presence of detect-pr-changes.sh also explains the release cadence visible in the repository's tags. The recent releases are per package rather than for the repository as a whole: Google.Cloud.CloudBuild.V1 at 2.21.0, Google.Cloud.AlloyDb.V1 at 1.16.0, and Google.Cloud.Memorystore.V1Beta at 1.0.0-beta07, all dated 2026-10-12. A Cloud Build client with a version above two and a Memorystore beta client still on its first beta are two very different maturity stories sitting in the same release batch.

V1, V1Beta and V1Alpha are the real version signal

Look at the version column rather than the package column when you assess a dependency, because the two encode different things.

The package version says how many times that client has been released. CloudBuild.V1 at 2.21.0 has been through twenty-one minor releases of a stable API client, and each of those is a compatibility promise to the code using it.

The API version in the package name says how settled the service surface is. A V1 client tracks a generally available API. A V1Beta client tracks a surface that Google still changes, and a V1Alpha client one that is earlier still. The version in the table confirms it: Google.Cloud.Memorystore.V1Beta is at 1.0.0-beta07, so the client itself is still in its own beta series, and the two counters are independent.

That independence is worth internalising because it cuts both ways. A mature client for a young API can still change under you when Google changes the API, and a young client for an old API may simply not have been maintained because the service did not need it. The table's structure, package, latest version, description, is enough to make that judgement, which is why it is the first thing to read.

The service documentation links in the description column point at the service itself rather than at a specific API version: the AlloyDB V1 and V1Alpha entries link to the same AlloyDB documentation.

Conformance tests and containers are how the clients are checked

A generated client that is wrong in a subtle way is worse than no client, because the code compiles and the calls succeed. The testing apparatus in this repository is aimed at that problem.

There is a conformance-tests/ directory at the top level, together with updateconformancetests.sh to keep it in step with the API definitions. Conformance tests are the mechanism for checking that a client behaves the way the API contract says it should, across the many packages in the repository, rather than each one relying on a hand written example.

Alongside that, runintegrationtests.sh and run-container-tests.sh point at two different levels of verification. Integration tests need something real to talk to, and the docker/ directory exists to provide it, so a test can run against an emulator or a local service in a container rather than against the live API. That is a meaningful difference for a cloud client library, where the alternative is a test suite that needs credentials and a bill.

The documentation of the process is unusually thorough for a generated repository, and it is a good sign about the maintainers. There is ENVIRONMENT.md for setting up a development environment, TESTING.md for the test strategy, PROCESSES.md for the workflows, CONVENTIONS.md for the coding conventions, NEWAPI.md for adding a new API, BACKLOG.md for the work in progress. SECURITY.md, CODE_OF_CONDUCT.md and a conventional-commits-based release process are also present.

A contributor reading NEWAPI.md and PROCESSES.md has the map of how a new service gets a client, which is the question most people arrive at this repository with.

Adding a client to a project, without guessing

The README does not contain a code snippet, and it is worth being precise about that, because it means the installation path is the standard NuGet one and the API reference is the documentation.

The flow is short. Find the service in the available APIs table, note the package name and the latest version, and take the package from NuGet, where the table links directly to the package page on nuget.org, and the service documentation from the description column.

Two decisions deserve attention before you commit to a package. The first is the API version, because choosing V1Beta over V1 means accepting that the surface can change under you, and choosing V1 means accepting only that the service is settled. The second is whether the client version in the table is one you want to pin, which for a stable client is usually the right thing to do, since the version numbers in the table are per service and do not move in step with each other.

The API documentation at the reference site, linked from the top of the README, is where the client surface itself is described, and the repository's docs/ directory and the uploaddocs.sh script are how that documentation is produced and published, so the reference you read is generated from the same source as the code you call.

For the .NET idiomatic part, the promise is in the library design rather than in the README, and the practical test is whether the surface matches the conventions your existing code already uses. If it does not, the cost of using it is not the API calls but the shape of the objects, which is the part that a team's code review will notice first.

Editorial conclusion

google-cloud-dotnet suits a .NET team that calls Google Cloud or Google Workspace APIs and wants the official idiomatic client rather than a hand rolled REST wrapper, and that prefers many small packages over one large dependency. It does not suit a team that wants a single package to reference, nor one that needs a service released after the client library catches up, since the version table shows how far apart those can be. Verify first that the API version you need is published for the service you are calling, whether V1, V1Beta or V1Alpha, and read the ENVIRONMENT.md and TESTING.md documents before assuming the local build behaves like the published package.

Frequently asked questions

Official sources

1. googleapis/google-cloud-dotnet on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases