GoogleCloudPlatform/dotnet-docs-samples is a wall of Visual Studio solutions, not a library

One repository of standalone programs, not a NuGet package you reference

GoogleCloudPlatform/dotnet-docs-samples is a collection of C# programs rather than a library you consume from a package feed. The README describes it as samples that demonstrate how to call some Google Cloud services from C#, and it immediately narrows the scope: the samples cover only some of the total APIs that you can call from .NET. That caveat is the single most important fact about the project, because the repository is often mistaken for a reference implementation of the whole Google Cloud surface in .NET.

The full list of callable APIs lives elsewhere, on the APIs and .NET Libraries page the README links to, and the README also points readers to Google Cloud Samples for browsing a wider set of code. So the repository sits inside a documentation ecosystem rather than beside it. What you find here is code whose purpose is to be read, copied, and adjusted until it does what you want.

The primary language is C#, the default branch is main, and the homepage is the .NET developer hub at cloud.google.com/dotnet. The repository is not archived, and the last push landed on 2026-09-14, so the code is in active circulation rather than frozen.

Cloning the repo and opening a solution in Visual Studio

The README gives a short build path. The first step is to get the code locally, and the repository states the exact command:

git clone https://github.com/GoogleCloudPlatform/dotnet-docs-samples

After cloning, the README asks you to browse the directories, find a solution file, open it with Visual Studio 2017 or later, and build it. That is the whole toolchain requirement: a Windows development machine with Visual Studio, and nothing else such as a Makefile, a dotnet CLI script, or a container image.

The README has a quirk worth knowing before you follow it. Its setup list is numbered 1 and then 6, so the two steps look like fragments of a longer list that was trimmed. The surviving items are the one that matters most, following the set-up instructions in the documentation, and the clone step. Because no sample works until the set-up step is done, the numbering should not be read as a sign that steps two through five were dropped with useful content in them.

Once a solution is open, the interesting part is that the project file in each directory carries the service client dependency and the code in the program file makes one concrete call. You run it locally, and it talks to the real service, which is also why the credential step is not optional.

Forty-four service directories that mirror the Google Cloud catalog

The top level of the repository is a directory per service, and the count tells you the shape of the project better than the README does. There are 44 directories named for products or service areas, including aiplatform, appengine, asset, auth, bigquery, bigquery-storage, bigtable, cdn, cloud-sql, cloudtasks, compute, datastore, dlp, documentai, endpoints, error-reporting, eventarc, firestore, functions, genai, iam, identity-aware-proxy, kms, logging, media, modelarmor, monitoring, parametermanager, powershell, pubsub, retail, run, secretmanager, securitycenter, servicedirectory, spanner, storage, storagebatchoperations, storageinsights, storagetransfer, testutil, and getting-started.

The naming is inconsistent in a way that is only visible from the listing. Some directories are named after a single service, others after a product family, and a few, such as applications and getting-started, are groupings rather than services. There is no index file in the root that maps a service name to its sample, so finding the right sample means either knowing the directory naming or scanning the tree.

Alongside the service directories sit a small number of build and governance files: Directory.Build.props at the root, which is where shared build settings would live, a BuildTools.psm1 PowerShell module, a buildAndRunTests.ps1 script, an .editorconfig file, CODEOWNERS, CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, and TESTING.md. The .kokoro and .kokoro-windows directories point to the continuous integration setup the project uses.

The setup step lives in external documentation, and the README is blunt about it

The most consequential line in the README is also the shortest. It states that no sample will work until you follow the set-up instructions in the documentation, and the link points to the .NET setup page on cloud.google.com. Everything the sample needs to reach a live Google Cloud API, from environment configuration to whatever the service requires before a call succeeds, is defined on that page and nowhere in the repository.

This is a deliberate boundary rather than an omission. Samples published alongside documentation are meant to be paired with that documentation, and the repository avoids duplicating setup steps that would then drift. The cost falls on the reader who wants to run something immediately, because the code in a directory and the environment it expects are separated by a documentation hop that the repository does not summarize.

The README is also silent on which credentials, project settings, or billing accounts a given sample needs, and it says nothing about how to point a sample at your own project. If a sample fails on first run, the repository gives you no troubleshooting section to consult, so the setup page and the service documentation remain the only places to look.

The test suite is knowingly incomplete, and CI configuration is not documented

The README carries a note that explains a gap in coverage better than most projects would. Tests for the Anywhere Cache samples are not included because creating an AnywhereCache can take an extremely long time, sometimes up to 48 hours. The reasoning is sound, since a test that blocks a pipeline for two days is worse than no test, but the effect is that the samples in that area arrive without the automated checks the other areas have.

The repository does contain the machinery for testing. TESTING.md is referenced from the README, a buildAndRunTests.ps1 script sits at the root, and two continuous integration directories exist with a Windows specific variant. What is missing is the command that a new user would type. The README does not document how to invoke the test script, what it expects to be installed, or how the two continuous integration configurations are driven, so anyone who wants to run the tests locally has to read those files directly.

A PowerShell module named BuildTools.psm1 and the root Directory.Build.props suggest the shared build and test logic is factored out for reuse across directories. That is a reasonable layout for a repository this size, and it also means each service directory is expected to look nearly identical, which is helpful when you copy one sample as the starting point for another.

Apache-2.0 covers the code, and the notice obligations come with it

The project is licensed under Apache-2.0, and the LICENSE file sits in the repository root alongside a CODE_OF_CONDUCT.md, a SECURITY.md, and a CONTRIBUTING.md. The governance files are thin pointers rather than policy documents, which is normal for a sample collection and means the practical rules for a contribution live in CONTRIBUTING.md rather than in the README.

If you copy a sample into your own product, the Apache-2.0 terms travel with the code you took. The license is built around a broad grant of copyright and patent rights, conditional on retaining the applicable copyright and license notices and on marking modified files. It is not a permissive license that lets you drop the header without consequence. Whether that obligation matters for your situation is a question for whoever handles licensing in your organization, not something this repository answers.

One practical point does follow from the layout. Because each service directory is a self-contained sample with its own project file and its own code, copying one directory is a clean way to take a working example, and the notices inside that directory are the ones you keep.

No releases, no versioned artifacts, and a wide surface to search

The repository publishes no GitHub releases, which means there is no version to pin, no changelog to read, and no artifact to download. You take whatever is on the main branch at the moment you clone. For a documentation sample that is an acceptable model, since the code is meant to be read and adapted rather than deployed, but it removes a signal engineers normally rely on when deciding whether a sample matches the current service API.

The last push on 2026-09-14 tells you the work is current, and the breadth of the directory list tells you the surface is large enough that some samples will lag behind a service release even while the repository as a whole is active. The README does not promise that every sample tracks the latest version of its service, and it offers no per-sample freshness indicator.

The practical compromise is to treat a directory as a working sketch of one call, then confirm the API shape against the service documentation for the client library version your own project uses. The samples are strongest as a map of where the calls live in the client library, and weakest as a guarantee that the call shape has not moved since the last push.

Editorial conclusion

Adopt this repository when you need one working C# example of a specific Google Cloud API call and are prepared to finish the credential setup the README defers to external documentation. Do not adopt it as a shared client library, a starter kit, or a source of release and version information, since it publishes no GitHub releases and covers only some of the APIs callable from .NET. Before starting, confirm that a directory exists for the service you care about, and read the set-up instructions the README points to, because the README states that no sample works until those steps are done.

Frequently asked questions

Official sources

1. GoogleCloudPlatform/dotnet-docs-samples on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README