What Is Nuget In C# Download For Mac

-->

Cross platform Xamarin plugin to play Media from PCL. Supports audio and video playback on Android, iOS, UWP, tvOS and Mac. NuGet is the package manager for.NET. The NuGet client tools provide the ability to produce and consume packages. The NuGet Gallery is the central package repository used by all package authors and consumers.

NuGet is the most popular package manager for .NET development and is built in to Visual Studio for Mac and Visual Studio on Windows. You can search for and add packages to your Xamarin, .NET Core and ASP.NET projects using either IDE.

This article describes how to include a NuGet package in a project and demonstrates the tool chain that makes the process seamless.

NuGet in Visual Studio for Mac

To demonstrate the NuGet package functionality, we'll first walk through creating a new application and adding a package to it. Then we'll discuss the IDE features that help manage packages.

Create a new project

First, create a project named HelloNuget as illustrated below. This example shows the iOS Single View Application template, but any supported project type would work:

Adding a Package

With the project open in Visual Studio for Mac, right-click on the Packages folder in the Solution Pad and select Add NuGet Packages:

This launches the Add Packages window. Ensure that the Source drop-down, is set to nuget.org:

When the window opens it loads a list of packages from the default package source: nuget.org. The initial results look like this:

Use the search box in the top-right corner to find a specific package, for example azure mobile. When you have found a package that you wish to use, select it and click the Add Package button to begin installation.

Once the package has been downloaded, it will be added to your project. The solution will change as follows:

The References node will contain a list of all the assemblies that are part of a NuGet package.
The Packages node displays each NuGet package that you have downloaded. You can update or remove a package from this list.
A packages.config file will be added to the project. This XML file is used by the IDE to track which package versions are referenced in this project. This file should not be hand-edited, but you should keep it in version control. Note that a project.json file can be used instead of a packages.config file. The project.json file is a new package file format introduced with NuGet 3, which supports transitive restore. More detailed information on project.json can be found in the NuGet documentation. The project.json file needs to be added manually and the project closed and re-opened before the project.json file is used in Visual Studio for Mac.

Using NuGet Packages

Once the NuGet package has been added and the project references updated, you can program against the APIs as you would with any project reference.

Ensure that you add any required using directives to the top of your file:

Most NuGet provide additional information, such as a README or Project page link to the Nuget source. You can normally find a link to this in the package blurb on the Add Packages page:

Package Updates

Package updates can be done either all at once, by right-clicking on the Packages node, or individually on each component.

Right-click on Packages to access the context menu:

Add NuGet Packages - Opens the window to add more packages to the project.
Update - Checks the source server for each package and downloads any newer versions.
Restore - Downloads any missing packages (without updating existing packages to newer versions).

Update and Restore options are also available at the Solution level, and affect all the projects in the solution.

You can also right-click on individual packages to access a context menu:

Version Number - The version number is a disabled menu item - it is provided for informational purposes only.
Update - Checks the source server and downloads a newer version (if it exists).
Remove - Removes the package from this project and removes the relevant assemblies from the project's References.

Adding Package Sources

Packages available for installation are initially retrieved from nuget.org. However, you can add other package locations to Visual Studio for Mac. This can be useful for testing your own NuGet packages under development, or to use a private NuGet server inside your company or organization.

In Visual Studio for Mac, navigate to Visual Studio > Preferences > NuGet > Sources to view and edit the list of package sources. Note that sources can be a remote server (specified by a URL) or a local directory.

Click Add to set-up a new source. Enter a friendly name and the URL (or file path) to the package source. If the source is a secure web server, enter the username and password as well, otherwise leave these entries blank:

Different sources can then be selected when searching for packages:

Version Control

The NuGet documentation discusses using NuGet without committing packages to source control. If you prefer not to store binaries and unused information in source control, you can configure Visual Studio for Mac to automatically restore packages from the server. This means that when a developer retrieves the project from source control for the first time, Visual Studio for Mac will automatically download and install the required packages.

Refer to your particular source control documentation for details on how to exclude the packages directory from being tracked.

The flow of packages between creators, hosts, and consumers

In its role as a public host, NuGet itself maintains the central repository of over 100,000 unique packages at nuget.org. These packages are employed by millions of .NET/.NET Core developers every day. NuGet also enables you to host packages privately in the cloud (such as on Azure DevOps), on a private network, or even on just your local file system. By doing so, those packages are available to only those developers that have access to the host, giving you the ability to make packages available to a specific group of consumers. The options are explained on Hosting your own NuGet feeds. Through configuration options, you can also control exactly which hosts can be accessed by any given computer, thereby ensuring that packages are obtained from specific sources rather than a public repository like nuget.org.

Whatever its nature, a host serves as the point of connection between package creators and package consumers. Creators build useful NuGet packages and publish them to a host. Consumers then search for useful and compatible packages on accessible hosts, downloading and including those packages in their projects. Once installed in a project, the packages' APIs are available to the rest of the project code.

Package targeting compatibility

A 'compatible' package means that it contains assemblies built for at least one target .NET framework that's compatible with the consuming project's target framework. Developers can create packages that are specific to one framework, as with UWP controls, or they can support a wider range of targets. To maximize a package's compatibility, developers target .NET Standard, which all .NET and .NET Core projects can consume. This is the most efficient means for both creators and consumers, as a single package (usually containing a single assembly) works for all consuming projects.

Package developers who require APIs outside of .NET Standard, on the other hand, create separate assemblies for the different target frameworks they want to support and include all of those assemblies in the same package (which is called 'multi-targeting'). When a consumer installs such a package, NuGet extracts only those assemblies that are needed by the project. This minimizes the package's footprint in the final application and/or assemblies produced by that project. A multi-targeting package is, of course, more difficult for its creator to maintain.

Note

Targeting .NET Standard supersedes the previous approach of using various portable class library (PCL) targets. This documentation therefore focuses on creating packages for .NET Standard.

NuGet tools

In addition to hosting support, NuGet also provides a variety of tools used by both creators and consumers. See Installing NuGet client tools for how to obtain specific tools.

Tool	Platforms	Applicable Scenarios	Description
dotnet CLI	All	Creation, Consumption	CLI tool for .NET Core and .NET Standard libraries, and for SDK-style projects that target .NET Framework (see SDK attribute). Provides certain NuGet CLI capabilities directly within the .NET Core tool chain. As with the `nuget.exe` CLI, the dotnet CLI does not interact with Visual Studio projects.
nuget.exe CLI	All	Creation, Consumption	CLI tool for .NET Framework libraries and non-SDK-style projects that target .NET Standard libraries. Provides all NuGet capabilities, with some commands applying specifically to package creators, some applying only to consumers, and others applying to both. For example, package creators use the `nuget pack` command to create a package from various assemblies and related files, package consumers use `nuget install` to include packages in a project folder, and everyone uses `nuget config` to set NuGet configuration variables. As a platform-agnostic tool, the NuGet CLI does not interact with Visual Studio projects.
Package Manager Console	Visual Studio on Windows	Consumption	Provides PowerShell commands for installing and managing packages in Visual Studio projects.
Package Manager UI	Visual Studio on Windows	Consumption	Provides an easy-to-use UI for installing and managing packages in Visual Studio projects.
Manage NuGet UI	Visual Studio for Mac	Consumption	Provide an easy-to-use UI for installing and managing packages in Visual Studio for Mac projects.
MSBuild	Windows	Creation, Consumption	Provides the ability to create packages and restore packages used in a project directly through the MSBuild tool chain.

As you can see, the NuGet tools you work with depend greatly on whether you're creating, consuming, or publishing packages, and the platform on which you're working. Package creators are typically also consumers, as they build on top of functionality that exists in other NuGet packages. And those packages, of course, may in turn depend on still others.

For more information, start with the Package creation workflow and Package consumption workflow articles.

Managing dependencies

The ability to easily build on the work of others is one of most powerful features of a package management system. Accordingly, much of what NuGet does is managing that dependency tree or 'graph' on behalf of a project. Simply said, you need only concern yourself with those packages that you're directly using in a project. If any of those packages themselves consume other packages (which can, in turn, consume still others), NuGet takes care of all those down-level dependencies.

The following image shows a project that depends on five packages, which in turn depend on a number of others.

Minecraft on New 3DS supports clever use of the dual-screens, allowing you to fiddle with your crafting kit on one without obscuring the game world on the other. Ftb launcher download for mac. Available digitally on Nintendo eShop. Don’t be fooled by the handheld’s compact size: we’ve packed worlds of 2016x2016 blocks onto Nintendo’s mighty portable!

Notice that some packages appear multiple times in the dependency graph. For example, there are three different consumers of package B, and each consumer might also specify a different version for that package (not shown). This is a common occurrence, especially for widely-used packages. NuGet fortunately does all the hard work to determine exactly which version of package B satisfies all consumers. NuGet then does the same for all other packages, no matter how deep the dependency graph.

For more details on how NuGet performs this service, see Dependency resolution.

Tracking references and restoring packages

Because projects can easily move between developer computers, source control repositories, build servers, and so forth, it's highly impractical to keep the binary assemblies of NuGet packages directly bound to a project. Doing so would make each copy of the project unnecessarily bloated (and thereby waste space in source control repositories). It would also make it very difficult to update package binaries to newer versions as updates would have to be applied across all copies of the project.

NuGet instead maintains a simple reference list of the packages upon which a project depends, including both top-level and down-level dependencies. That is, whenever you install a package from some host into a project, NuGet records the package identifier and version number in the reference list. (Uninstalling a package, of course, removes it from the list.) NuGet then provides a means to restore all referenced packages upon request, as described on Package restore.

With only the reference list, NuGet can then reinstall—that is, restore—all of those packages from public and/or private hosts at any later time. When committing a project to source control, or sharing it in some other way, you include only the reference list and exclude any package binaries (see Packages and source control.)

The computer that receives a project, such as a build server obtaining a copy of the project as part of an automated deployment system, simply asks NuGet to restore dependencies whenever they're needed. Build systems like Azure DevOps provide 'NuGet restore' steps for this exact purpose. Similarly, when developers obtain a copy of a project (as when cloning a repository), they can invoke command like nuget restore (NuGet CLI), dotnet restore (dotnet CLI), or Install-Package (Package Manager Console) to obtain all the necessary packages. Visual Studio, for its part, automatically restores packages when building a project (provided that automatic restore is enabled, as described on Package restore).

Clearly, then, NuGet's primary role where developers are concerned is maintaining that reference list on behalf of your project and providing the means to efficiently restore (and update) those referenced packages. This list is maintained in one of two package management formats, as they're called:

PackageReference (or 'package references in project files') | (NuGet 4.0+) Maintains a list of a project's top-level dependencies directly within the project file, so no separate file is needed. An associated file, obj/project.assets.json, is dynamically generated to manage the overall dependency graph of the packages that a project uses along with all down-level dependencies. PackageReference is always used by .NET Core projects.
So you’ll experience pristine video quality wherever you watch your movies or videos. QuickTime lets you do more with your digital media. It’s a flexible file format. Quicktime player for windows 10.
packages.config: (NuGet 1.0+) An XML file that maintains a flat list of all dependencies in the project, including the dependencies of other installed packages. Installed or restored packages are stored in a packages folder.

Which package management format is employed in any given project depends on the project type, and the available version of NuGet (and/or Visual Studio). To check what format is being used, simply look for packages.config in the project root after installing your first package. If you don't have that file, look in the project file directly for a <PackageReference> element.

When you have a choice, we recommend using PackageReference. packages.config is maintained for legacy purposes and is no longer under active development.

Tip

Various nuget.exe CLI commands, like nuget install, do not automatically add the package to the reference list. The list is updated when installing a package with the Visual Studio Package Manager (UI or Console), and with dotnet.exe CLI.

What else does NuGet do?

So far you've learned the following characteristics of NuGet:

C# 2008 Download

NuGet provides the central nuget.org repository with support for private hosting.
NuGet provides the tools developers need for creating, publishing, and consuming packages.
Most importantly, NuGet maintains a reference list of packages used in a project and the ability to restore and update those packages from that list.

To make these processes work efficiently, NuGet does some behind-the-scenes optimizations. Most notably, NuGet manages a package cache and a global packages folder to shortcut installation and reinstallation. The cache avoids downloading a package that's already been installed on the machine. The global packages folder allows multiple projects to share the same installed package, thereby reducing NuGet's overall footprint on the computer. The cache and global packages folder are also very helpful when you're frequently restoring a larger number of packages, as on a build server. For more details on these mechanisms, see Managing the global packages and cache folders.

Within an individual project, NuGet manages the overall dependency graph, which again includes resolving multiple references to different versions of the same package. It's quite common that a project takes a dependency on one or more packages that themselves have the same dependencies. Some of the most useful utility packages on nuget.org are employed by many other packages. Univers lt std font free download for mac. In the entire dependency graph, then, you could easily have ten different references to different versions of the same package. To avoid bringing multiple versions of that package into the application itself, NuGet sorts out which single version can be used by all consumers. (For more information, see Dependency Resolution.)

Beyond that, NuGet maintains all the specifications related to how packages are structured (including localization and debug symbols) and how they are referenced (including version ranges and pre-release versions.) NuGet also provides various APIs to work with its services programmatically, and provides support for developers who write Visual Studio extensions and project templates.