NuGet.Client: the four client front ends behind NuGet packages

Four front ends sharing one C# implementation

The repository bills itself as client tools for NuGet, and the README lists the clients it contains in four lines:

- [NuGet CLI](https://docs.microsoft.com/nuget/tools/nuget-exe-cli-reference)
- [NuGet Package Manager for Visual Studio](https://docs.microsoft.com/nuget/tools/package-manager-ui)
- [PowerShell CmdLets](https://docs.microsoft.com/nuget/tools/powershell-reference)
- [NuGet functionality for dotnet.exe](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet)

The value of the grouping is that these are not four separate implementations with four separate bug lists. A change to package installation or restore logic lands in shared source and propagates to the command line tool, the Visual Studio extension, the PowerShell surface and dotnet.exe at the same time. For a maintainer that is an efficiency win. For someone reporting a bug, it explains why a fix sometimes lands in a front end they did not touch.

The primary language is C# and the repository description is explicit that it covers Visual Studio extensions, command line tools and msbuild support. The default branch is dev, not master, which tells you the branch layout is not the GitHub default most projects use.

The documentation also points out where the work actually gets coordinated. It describes NuGet/Home as the starting point for all things NuGet and the home of the issue tracker, with basic information about everything NuGet, and asks contributors to consult it before beginning a journey through NuGet code. The repository's own description repeats the point: open issues belong at https://github.com/nuget/home/issues, not in this repository.

Solution filters instead of one giant solution

The repository layout is the clearest signal about the size of the codebase. There is a NuGet.sln at the root, and alongside it five solution filters: NuGet-Src.slnf, NuGet-VS.slnf, NuGet-UnitTests.slnf, NuGet-Src-Commandline.slnf and NuGet-Commandline-WithTests.slnf.

Those filters exist so a contributor or CI agent can open a subset of the solution rather than the whole thing. NuGet-Src.slnf and NuGet-VS.slnf split the core source from the Visual Studio pieces, and the commandline filters isolate the command line projects with and without their tests. This is a deliberate concession to the fact that the full solution is too large to load comfortably for every task, which is the same reason the build directory carries separate entry points.

Central package management is visible in the root as well. Directory.Packages.props sits next to Directory.Build.props, Directory.Build.targets, Directory.Solution.targets, Directory.Build.rsp and global.json, which together are the standard set of files for pinning package versions in one place and setting the SDK version and shared MSBuild properties. The presence of a .vsconfig file points at the Visual Studio component set the team expects, and .config, .editorconfig and .git-blame-ignore-revs handle formatting and blame noise across a large history.

Build and test entry points for three operating systems

The repository ships parallel scripts rather than one canonical command, and the naming makes the mapping obvious. There is build.cmd, build.ps1 and build.sh, then configure.cmd, configure.ps1 and configure.sh, and separately runTests.cmd and runTests.ps1.

So a Windows contributor drives the flow through the .cmd and .ps1 files, and a Unix or macOS contributor uses build.sh and configure.sh. The split between configure and build suggests a two-step flow where configuration settles the environment before a build runs, and runTests is kept apart so the test phase can be invoked on its own. There is also a .azuredevops directory for the pipeline definitions, a scripts directory, an eng directory for shared engineering tooling, a setup directory, a keys directory and a tools-local directory for locally acquired tooling.

The build also uses a .gitmodules file, so parts of the build tree come from other repositories, and the es-metadata.yml file is part of the localization metadata set. A spelling.dic file at the root is a small but revealing detail: in a repository with this many strings and comments, keeping the spell checker quiet takes a dictionary of its own.

Where bugs, contributions and security reports each go

The documentation separates three channels that new contributors routinely confuse.

Bug reports go to the issue tracker in NuGet/Home, not to this repository. The documentation states it twice, once in the NuGet/Home section and once in the Feedback section: file NuGet.Client bugs in the NuGet/Home repository.

Contributions belong here, and only here. The documentation gives the official location as https://github.com/NuGet/NuGet.Client and states that the NuGet team does not accept pull requests in other locations. The Getting Started section points to the Contributing doc for how to contribute to this repo, and CONTRIBUTING.md is present at the root.

Security issues follow a separate process, described in SECURITY.md, which is also at the root. The documentation is explicit that security issues must follow that process, and it also names the contact address [email protected] for questions or comments.

The project has adopted the Microsoft Open Source Code of Conduct, with the Code of Conduct FAQ and the same contact address offered for anything further. CODE-OF-CONDUCT.md sits at the root of the repository alongside the .github directory, which typically holds the issue and pull request templates for a project of this size.

The 2016 release tags do not describe the current code

The published releases tell a confusing story, and it is worth naming rather than glossing over. The most recent release tags visible are 3.5.0-beta2-final, described as a release of NuGet Package Manager for Visual Studio 2015, and 3.4.4-rtm with the same Visual Studio 2015 description, both dated 2016-06-27. Before them is v3.4.3.855-VSIX-Dev14 from 2016-04-22.

Every one of those tags is a Visual Studio 2015 era artefact from six years before the last push. The source tree, by contrast, is current: the last push on the dev branch was on 2026-10-20, and the root files include modern tooling such as global.json for SDK pinning, Directory.Packages.props for central package version management, and a .git-blame-ignore-revs file.

The reasonable reading is that the GitHub release list here is a historical archive of the old Visual Studio extension releases rather than a description of how the current binaries are shipped, and that the actual versioning of the tool happens in the Visual Studio extension and dotnet.exe channels rather than through tags in this repository. The documentation itself does not discuss the release process or how to obtain a build, so a contributor looking for a release procedure in the documentation will not find one. The repository's stated answer to that question is the Contributing doc.

Licensing, and why the licence field is unusual

The licence is where NuGet.Client differs from most open source repositories you will evaluate. The repository carries LICENSE.txt at the root, and the README states that unless explicitly stated otherwise all files in this repository are licensed under the License in the root repository. The licence itself is recorded as a custom licence that GitHub cannot classify.

That is worth pausing on rather than treating as a formality. A permissive standard licence such as MIT or Apache-2.0 is the default assumption many teams make when they see a public repository, and here that assumption does not hold. The NOTICE file is not present, but there is a docs directory, a setup directory and an es-metadata.yml file, so the repository is not minimal in what it ships alongside the code. Any organisation planning to vendor or redistribute code from this repository, or to depend on it as a published package, needs to read LICENSE.txt and confirm the terms with its own legal review. No general advice about what the custom terms permit is possible from the documentation alone.

One other governance point is stated plainly. The project follows the Microsoft Open Source Code of Conduct, and CONTRIBUTING.md, SECURITY.md and CODE-OF-CONDUCT.md are all tracked in the repository root, which tells you the process documentation is treated as part of the product rather than as an afterthought.

Editorial conclusion

NuGet.Client is the repository to work in when you need to change package restore, install or publish behaviour for .NET users, and it is where fixes land for all four client front ends at once. It is the wrong repository for anything unrelated to the client tools, such as the dotnet SDK itself or the NuGet/Home documentation site. Before you open a pull request, check that the NuGet team accepts contributions only at github.com/NuGet/NuGet.Client, read CONTRIBUTING.md for the setup steps, and route anything security related through SECURITY.md instead of the public issue tracker. The last push on the default branch, dev, was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. NuGet/NuGet.Client on GitHub
3. README
4. Releases