Azure Artifacts in Azure DevOps PDF

Contents
Azure Artifacts Documentation

What is Azure Artifacts?
Start using Azure Artifacts
Azure Artifacts basics
Key concepts
Where is Package Management?
Artifact Storage (New UI)
Best practices
Complete graphs
Collaborate with packages
Limits on package sizes and counts
Use the .artifactignore file
Artifact feeds
What are feeds?
Understanding project-scoped feeds
What are feed views?
Create a private PowerShell repository
Share packages publicly
Protect OSS packages with upstream sources
Promote a package to a view
Migrate packages to Azure Artifacts
Move your packages to the cloud
Set feeds and views permissions and grant access
Understanding upstream sources
Set up upstream sources
Use badges to share your packages
Delete and recover packages
Follow a package for publish alerts
NuGet
NuGet quickstart
Publish to a NuGet feed (YAML/Classic)
Publish a NuGet package from the command line
Consume NuGet packages in Visual Studio
Use NuGet with Azure DevOps Services
Use dotnet with Azure DevOps Services
Use NuGet or dotnet with TFS
Use packages from nuget.org
Set up a multi-developer environment
npm
npm quickstart
Publish to an npm feed (YAML/Classic)
Publish an npm package from the command line
Set up your project's npmrc
Use packages from npmjs.com
Use npm scopes
Use npm audit
Maven
Maven quickstart
Set up a project to work with Maven feed
Publish a Maven package from the command line
Set up authentication
Install a Maven artifact
Use packages from Maven Central
Python
Python quickstart
Publish to a Python feed
Universal Packages
Universal packages quickstart
Publish to a Universal feed (YAML/Classic)
Gradle
Install a Maven artifact using Gradle
Publish a Maven artifact using Gradle
Symbols
Symbol files
Use symbols in Visual Studio
Use symbols in WinDbg
Publish symbols
Setting up GitHub SourceLinking
What is Azure Artifacts?
11/2/2020 • 2 minutes to read • Edit Online
Azure DevOps Ser vices | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 - TFS
2017
With Azure Artifacts you can create and share Maven, npm, and NuGet package feeds from public and private
sources with teams of any size. You can add fully integrated package management to your continuous
integration/continuous delivery (CI/CD) pipelines with a single click.
Azure Artifacts is an extension to Azure DevOps Services and Azure DevOps Server. It comes pre-installed in Azure
DevOps Services, Azure DevOps Server 2019, and 2020 and Team Foundation Server (TFS) 2017 and 2018.
NOTE
Azure Ar tifacts is the new home of the Packages page under the Build and release page group in the previous
navigation UX of Azure DevOps Services and TFS.
Azure Artifacts overview

Azure Artifacts introduces the concept of multiple feeds that you can use to organize and control access to your
packages. If you're familiar with using packages from NuGet.org or npmjs, you can think of those places each as a
single feed.
A note on terminology: you might also have heard feeds called package repositories or package sources, especially
if you're an npm or Maven user.
Get started with using Azure Artifacts

Get up and running with NuGet, npm, and Maven in Azure DevOps Services and TFS in just a few minutes with the
NuGet quickstart, npm quickstart, and Maven quickstart.
If you haven't used packages before, see the conceptual introduction. When you're ready to get started, learn how
to assign Azure Artifacts licenses in your organization.
You can control the amount of packages you retain using Retention Policies in your feed settings. For more
information see automatically deleting old packages
Versions and compatibility

Some Azure Artifacts services are compatible with only specific versions of TFS. Check out the following table to
see compatibility.
F EAT URE A Z URE DEVO P S SERVIC ES T FS
NuGet Yes TFS 2017 and newer
npm Yes TFS 2017 Update 1 and newer
NuGet.org upstream source Yes TFS 2018 Update 2 and newer

F EAT URE A Z URE DEVO P S SERVIC ES T FS
Maven Yes TFS 2018 and newer
Maven Central upstream source Yes Azure DevOps Server 2019 Update 1
and newer, Azure DevOps Server 2020
Python Yes Azure DevOps Server 2019 Update 1

and newer, Azure DevOps Server 2020
Universal Packages Yes No
Other package types

Need to host other package types (Docker, CocoaPods, and so on)? Use the Suggest a feature link in Visual
Studio Developer Community.
Start using Azure Artifacts
2017
NOTE
If you're using a version of TFS, you need to license Azure Artifacts rather than set up billing.
Azure DevOps Ser vices

Learn how to go through the sign-up process for Azure Artifacts. Azure Artifacts is a service where you can create
package feeds to publish and consume the following package types:
Maven
npm
NuGet
Python
Universal Packages
Azure Artifacts gets billed on a consumption basis, and is free up until 2 GiB of storage. If your organization needs
more storage, you must set up billing.
Prerequisites
To start using Azure Artifacts, you need to have Project Collection Administrator or organization Owner
permissions.
Your network connection must be set up to allow certain IP addresses and domain URLs.
If you plan to use more than the free usage tier of 2 GiB, you must set up billing for your organization.
Users with a Basic license can create and consume Azure Artifacts. So, if you have a Basic license, you don't need
to purchase an Azure Artifacts extension.
Azure Artifacts is an extension to TFS. The Azure Artifacts extension comes pre-installed in TFS 2017 and 2018.
Azure Artifacts is required for each user who consumes or publishes packages to and from Azure Artifacts feeds.
The service currently supports the following package types: NuGet, npm, Python, Maven, and Universal Packages.
Install Azure Artifacts in TFS

Azure Artifacts is installed by default for TFS 2017 customers. Upgrade to TFS 2017 to use Azure Artifacts.
NOTE
If the Azure Artifacts extension has been removed, you can install it from the Marketplace page for Azure Artifacts.
Assign licenses in TFS

1. From any collection in TFS, hover over the settings menu and select the Users page. Then, select Azure
Ar tifacts .
2. Select Assign , enter the user to assign licenses, and then select Ok .
Users with Visual Studio Enterprise subscriptions get Azure Artifacts automatically.
Ensure that your Visual Studio Enterprise subscribers are assigned VS Enterprise Access level.
Billing and free monthly usage

Azure Artifacts includes a free usage tier of 2 GB. Any usage below this level isn't billed to your subscription.
Above this limit, we charge you for your actual usage. The usage limit allows you to control the maximum volume
of storage that you're billed for. Once the maximum usage limit is reached, you can no longer upload artifacts and
will need to either reduce your artifact storage, or increase your usage limit. For more information on usage tiers,
see the Azure Artifacts pricing page. For Microsoft-internal customers, please refer to internal documentation on
Microsoft pricing.
NOTE
Organizations created before May 6, 2019 will remain on the per-user billing model, and will be switched over to storage-
based charging as soon as November 1, 2020. More details on billing changes can be found on the Azure DevOps blog.
View artifact and billed storage

To see your storage bill for Azure Artifacts:
1. Sign in to your organization ( https://dev.azure.com/{yourorganization} ).
2. Select Organization settings .
3. Select Billing .
4. Find Artifacts and see your current billed usage from Azure Artifacts, or review a breakdown of the
different types of storage your organization is currently using. See the FAQs further in this article for
information on which artifacts count towards your storage total.
NOTE
Based on community feedback, we're working on more granular drilldowns and views into your artifact storage. More
information to come.
Pay for Azure Artifacts

Each organization gets Azure Artifacts for free, up until 2 GiB of storage is used. If you need more than 2 GiB, set
up billing.
If you've reached your storage limit, you'll be blocked from making additional uploads. It can take up to 1 hour
after increasing your limit for uploads to be re-enabled.
FAQs
Q: Which artifacts count toward my total billed storage?
A: Currently, the following get counted in your Azure Artifacts billed cost:
All packages (npm, NuGet, Python, Maven, and Universal Packages), including those packages stored from
upstream sources.
You're not billed by Azure Artifacts for storage of Pipeline Artifacts, Build Artifacts, and Pipeline Caching.
Q: Why do I see 0 GiB of storage, even though I'm storing artifacts?
A: 1 GiB is currently our lowest granularity, so you most likely haven't reached 1 GiB yet.
Q: How can I control how long artifacts are stored?
A: Retention for stored packages can be set via the feed retention policy. See how to automatically delete old
package versions with retention policies.
Q: How can I delete my artifacts?
A: To delete packages within your feeds, see delete and recover packages in Azure Artifacts.
Q: How long does it take for deleted artifacts to affect the amount of billed storage?
A: Deletion of artifacts doesn't register immediately. It can take up to 24 hours for the usage level to be updated. If
you're blocked from uploading artifacts, you can temporarily increase your usage level to continue publishing
artifacts. Then, reduce the level once the storage metrics are updated.
The 'used' value on the Billing tab of your Organization Settings page gets updated once per day. When you delete
artifacts, it may not reflect immediately on your billing page. The Artifact Storage tab gets updated more
frequently, so you may see a small discrepancy between the two.
Q: What happens if I remove my Azure Subscription from my Azure DevOps organization?
A: When you remove your Azure Subscription from your Azure DevOps organization, you only have access to the
free tier of storage (< 2 GiB). If you have above 2 GiB of used storage, you can only read packages. You can't push
packages until you lower your usage below 2 GiB, or you can reconnect an Azure subscription to your
organization and increase your storage tier appropriately.
Q: What about customers who were using Artifacts before May 6, 2019 under the previous per user model?
A: Customers from before May 6, 2019 aren't charged for Artifacts storage until November 1, 2020. You can opt in
to the new storage model by setting a paid limit above the amount of storage you're currently using. If you opt in,
your Azure bill will include the storage cost calculated from November 1 onward.
What's next?
Artifacts Storage breakdown
Key concepts for Azure Artifacts
Immutability
Once you publish a particular version of a package to a feed, that version number is permanently reserved. You
cannot upload a newer revision package with that same version number, or delete it and upload a new package at
the same version.
Many package clients, including NuGet and npm, keep a local cache of packages on your machine. Once a client
has cached a particular package@version , it will return that copy on future install/restore requests. If, on the server,
you replace package@version (rev 1) with a new package@version (rev 2), the client is unable to tell the difference.
This can lead to indeterminate build results from different machines. For example, a developer's machine and the
build agent might have cached different revisions of the package, leading to unexpected build results.
If a package is broken, buggy, or shares unintended content (like secrets), the best response is to prepare a fix and
publish it as a new version. Then, depending on the severity of the issue and how widely depended-on the package
is, you can delete the package to make it unavailable for consumption.
The only way to work around the immutability constraint is to create a new feed and publish the desired package
version to the new feed.
NOTE
If you delete a feed to recreate it, it will go in feed recycle bin and will be permanently deleted after 30 days. Feed name will
free up once the feed is permanently deleted from the feed recycle bin.
Recycle Bin
If you've deleted/unpublished an npm package, NuGet package, or Maven artifact from Azure DevOps Services,
builds that depend on that package will start to fail. You won't be able to repush that package to the feed because
of immutability. In order to recover the package and have builds start working again, a feed owner can recover it
from the Recycle Bin.
Once in the Recycle Bin, you will see any packages that have been deleted from the current feed in the past 30
days .
Package Management is now Azure Artifacts

Recently, Azure DevOps Services (previously Visual Studio Team Services) underwent a big UI update. This update
moved many popular hubs around, including the old Packages hub in the Build and Release hub group. As you
may know already, the Build and Release hub group has become Azure Pipelines , and the previous Packages
hub has been moved out to its own area known as Azure Ar tifacts .
How to find your packages in Azure DevOps Services

Before the UI update, your Package Management home was in the Packages hub of the Build and Release hub
group. You would navigate to it like so:
If you're still using the previous navigation, or TFS, this is still how you would access your packages.
The new update has introduced a new, top-level area that is the home of Package Management in Azure DevOps
Services. This area is known as Azure Ar tifacts and can be reached simply by selecting the Artifacts button on the
left of the UI:
NOTE
If you don't see Ar tifacts or want to turn the service off, see more info in Change service visibility
Azure Artifacts billing model

Azure Artifacts bills you on a consumption-basis and licenses are no longer required for Azure DevOps Services
customers. For more information, see Billing and free monthly usage for Azure Artifacts and What about customers
who were using Artifacts before May 6, 2019 under the previous per user model?
Artifact Storage breakdown
2017
Azure Artifacts offers a free tier plan that includes 2 GiB of free storage for different types of packages. Once you
reach your maximum storage limit, you can either upgrade to a paid subscription or delete some of your existing
artifacts.
Starting November 1st 2020, Azure Artifacts will be switching to a consumption-based billing for all package types
(NuGet, npm, Python, Maven, and Universal packages). Symbols storage will be free for now and billing it will be
deferred to a later time. For more information on the billing changes, check out the Billing changes blog post.
NOTE
Organizations created prior to May 6th 2019 will remain on the per-subscription billing and will switch over to per-storage
usage billing starting from November 1st 2020.
To have a better view of your storage consumption, Azure Artifacts is introducing a new user interface for Artifact
Storage to view your consumption from both an organization and a project levels. Storage will also be grouped by
type and/or by projects. More levels of granularity will be developed in the near future.
Organization-level storage
The organization-level view will show you your total storage summary and your storage consumption by Artifact
type and by project.
1. From within your organization, select Organization settings .
2. Under Artifacts, select Storage in the left navigation pane.
3. View your storage consumption for each section.
For the current release, users will be able to view the storage breakdown for packages as well as projects listed
under the Storage by projects section. We will be adding more levels of granularity in future releases.
The Packages storage breakdown view will list packages in organization-scoped feeds.
NOTE
The Storage by projects section will only show projects with the largest storage consumption and not the full list of
projects in your organization.
Project-level storage
The project-level view will show you your total storage summary as well as your storage consumption by Artifact
type.
1. From within your project, select Project settings .
2. Under Artifacts, select Storage in the left navigation pane.
3. View your total storage summary and your storage by Artifact type.
Your total storage summary will show you your total billable stored Artifacts. The storage by type section will list
your storage consumption by Artifact type. For the current release, you can view your storage breakdown for
Packages section only. The other sections will be added in future releases.
What's next?
What are feeds
What are feed views
Get started with NuGet packages
Publish to NuGet feeds (YAML/Classic)
Best practices for using Azure Artifacts
This article contains some general guidance and best practices when it comes to producing and consuming
packages in Azure DevOps Services or Team Foundation Server (TFS).
Creating packages as part of a build

Each repository should only reference one feed
A feed is a container for packages. You can have multiple feeds for different projects but a particular project should
only reference one feed. If you want to use packages from multiple feeds, use upstream sources to bring packages
from multiple feeds together into a single feed.
On package creation, automatically publish packages back to the feed.
This will populate the @local view of your feed. For more information on views, check out the views concept page.
Enable retention policies to automatically cleanup old package versions
Deleting old package versions improves client performance and releases storage space. You can choose how many
versions of a package to retain when setting up your retention policy.
Promote your package to the correct view
When a package is ready for early adopters, select that package and its dependency graph and promote it to the
@prerelease view.
When the package is deemed of sufficient quality to be released, promote that package and its dependency graph
into the @release view.
Promoting package versions to a view ensures they won't be deleted by retention policies. For more information on
views, check out the views concept page.
If external teams are consuming your package, ensure that your @release view and @prerelease view are visible
across the organizations
If these views aren't visible, teams won't have access to your packages.
Consuming packages from public and internal sources as part of a build

Each repository should have a unique feed
A feed is a container for packages, the only package source should be that single unique feed for each repository.
Configure upstream sources for public and internal sources
Add any public sources as a public upstream.
Add any internal sources as an Azure DevOps Services upstream.
Find out more information about upstream sources and how to configure upstream sources.
Sources not in your organization but in the same AAD tenant should be added using the feed locator
The feed locator uses the following syntax:
azure-feed://<organization>/<feed>@<view>
Ensure that the order of the sources matches your desired package resolution order
The feed will check each upstream in order, returning the package from the first source that can provide it.
To avoid confusion, we recommend placing any public upstreams FIRST in your resolution order
This prevents other sources from overriding well-known packages with altered or incompatible versions.
Constructing a complete package graph
Azure DevOps Ser vices | TFS 2017 (availability note)

When you release a package, it's important to ensure that any dependencies of that package are also available in
your feed, either by republishing them directly (not recommended) or by consuming them from an upstream
source. Once you consume a package from an upstream source once, a copy of it is always saved in your feed.
Even if the upstream source goes down, your copy will remain available both to you and to your downstream
consumers.
How upstreams construct the set of available packages

Because Azure DevOps Services feeds can have other Azure DevOps Services feeds as upstreams, it seems
possible on the surface to have a cycle of upstream sources, where feed A upstreams to feed B which upstreams to
feed C which upstreams back to feed A. Left unchecked, such a cycle could break package requests by creating an
infinite loop where a user asks A for a package, then A asks B, then B asks C, then C asks A again, etc. Upstream
sources are designed to prevent this.
When a feed consults its upstream sources for a package (step 3 in the search order), Azure DevOps Services
upstream sources will return the packages in the view configured for that upstream source. Thus, a query to feed A
does not actually result in a transitive query to feed C (A -> B -> C), because views are read-only. This means that
A has access to any packages from C that a user of B has previously saved into B, but not the full set of packages
available in C.
Thus, the onus falls to B to ensure that its local packages represent a complete dependency graph, so that users
who consume B's package via an upstream source from another feed are able to successfully resolve the graph
and install their desired B package.
Example: constructing the set of available packages

Assume three feeds, Fabrikam, Contoso, and AdventureWorks. In this example, we'll look at the packages available
to the Fabrikam feed as we add upstream sources.
At first, Fabrikam has no upstream sources, and users connected to Fabrikam can only install versions 1.0.0 and
2.0.0 of the Widgets package. Likewise, Contoso has no upstream sources, and users connected to Contoso can
only install versions 1.0.0 and 3.0.0 of the Gizmos package. Ditto for the AdventureWorks feed, where connected
users can only install versions 1.0.0 and 2.0.0 of the Gadgets package or version 1.0.0 of the Things package.
Next, consider what happens if Contoso adds an upstream source to AdventureWorks. Then, a user connected to
Contoso can install any version of Gizmos, any version of Gadgets, or any version of Things. If she installs
Gadgets@2.0.0, that package-version is saved into Contoso (with a link back to AdventureWorks).
Now, let's have the Fabrikam feed add an upstream source to the Contoso feed. Once that's done, a user connected
to Fabrikam can install any version of Widgets, any version of Gizmos, but only saved versions (i.e. 2.0.0) of
Gadgets.
He cannot install version 1.0.0 of Gadgets or any version of Things, because those package-versions haven't been
saved into Contoso by a Contoso user.
Collaborate more and build faster with packages
Azure DevOps Ser vices | TFS 2017

If you're familiar with componentization and composition, you can learn more about Azure Artifacts in Azure
DevOps Services and TFS.
Your product is successful, your organization is growing, and it's time to scale up your codebase to match. As you
scale out past 2-3 teams working in a single codebase on a single product, you may find yourself asking questions
like:
How do my teams effectively share reusable components?
How do I enable my feature teams to iterate rapidly without stepping on other teams' work?
How do I give my teams autonomy to iterate at the pace that's right for them?
These questions aren't just applicable to newly growing teams. If you're an established team with a legacy
codebase, you may be asking these same questions as you're being asked to deliver more value, ever faster.
Regardless of your situation, componentization can help you build a codebase that scales to the size of your team
and the speed of today's development.
In this article, we'll explore how binary composition through Azure Artifacts can help you manage and share your
external dependencies, your OSS, and your isolated shared components.
Components and composition

Componentization is the act of separating and structuring of your product into a set of components: discrete parts
of your codebase that provide a set of features. Most .NET projects already have some notion of components in the
form of the projects in your solution. For example, a simple website might have a front-end component, a data
access component, and a model/data storage component.
Source componentization
As your product grows, the solution + project model can become inefficient. Changes take longer to integrate and
are harder to merge, the build gets slower, and in some cases Visual Studio becomes slower. And, components start
to grow from a single project to multiple projects. Generally, this is the point at which teams start breaking out
these sets of related projects into separate solutions.
Once you've outgrown a single solution, how you componentize becomes an interesting question. We started with
source composition, where each component is referenced via a project reference in Visual Studio. Source
composition is possible as long as your source lives in a single composition boundary: a single solution within a
single source repository.
Unfortunately, these project references start to break down when multiple solutions are involved. At this point,
when solution A depends on solution B it must refer to the built binaries (i.e. DLLs) produced by solution B - this is
binary composition.
Accordingly, these binaries now need to be built and made available to A before A can build successfully. There are
a few ways to do that:
You can check them into source control. Depending on your source control system, binaries can quickly balloon
the size of your repo, slowing check-out times and general repo performance. If you start to work in branches,
multiple teams can end up introducing the same binary at different versions, creating nasty merge conflicts at
the root of the tree.
You can put them on a file share somewhere. File shares have a few limitations: there's no index for quick
lookups, and there's no protection against overwriting a version later.
Package componentization
Packages address many of the challenges of referencing binaries. Instead of checking them into source, you can
have a solution B produce its binaries into NuGet packages that another solution A can then consume. If solution A
and solution B are maintained as separate components, where simultaneous changes across A and B are rare,
package composition is a great way to manage the dependency of A on B. Package composition allows B to iterate
on its own cadence, while A is free to take updates to B when A's schedule permits, and it allows multiple teams to
iterate and provide updates to B without affecting A (or other solutions C or D).
Package composition isn't without its challenges though. Thus far, we've looked at a simple example. However,
scaling package composition up to the size of a large codebase (something like Windows or Bing) can cause a
series of challenges:
Understanding the impact of breaking changes in a component low in the dependency graph becomes very
challenging
Diamond dependencies can become a significant roadblock to agility. In a diamond dependency, components B
and C both depend on a shared component A, and D depends on B and C. A releases a new version with
breaking changes. If B updates, but C does not, D cannot take B's updates without introducing a dependency
conflict. In this simple example, a conversation with C may be all that's needed to resolve the conflict. However,
in a complex graph, diamonds can quickly become unresolvable.
If changes must be made across two components that are composed with packages, the dev inner loop is much
slower. When A is updated, it must be re-built, re-packaged, and re-published. B must then update to the newly-
published version to validate A's change. Source composition, which can build A and B simultaneously, will
always provide a faster inner loop for developers.
What should you use

In general, we've seen large teams be most successful when they use a mixture of composition strategies. To help
determine what's right for your codebase, first draw your product's dependency graph and start to group your
components into sets of related components. For example, you may have a set of components that make up your
framework, including common controls, etc., and a set of components that make up your user-facing service. Then,
for each set of related components, ask these questions:
Will my teams often make spanning check-ins across the sets I've created?
Is a single team responsible for the entire set?
For a single set, is there a shared release cadence?
At a high level, we've found the most success when source composition is used for related projects that are worked
on by a single team (or a group of related teams) and binary composition is used for OSS, externals (components
from faraway or isolated teams), and isolated shared components.
Jump in
If you're ready to get started with package componentization, check out the Azure Artifacts overview.
Limits
Azure Artifacts is a highly-scalable artifact service. In the course of everyday development, you shouldn’t need to
worry about limits on size and quantity of packages you store. However, the service does have some architectural
limits and also some limits imposed by the client tools (e.g. nuget.exe) it integrates with.
Count limits
5000 versions per package ID; use retention policies to automatically clean up old versions
Unlimited package IDs per feed
Size limits
NuGet packages are limited to 500 MB
npm packages are limited to 500 MB
Maven packages are limited to 500 MB per file
Python packages are limited to 500 MB per file
Universal Packages have been tested up to 1 TB and are recommended for managing large binary content
Use the .artifactignore file
The .artifactignore is a text file that controls what files are uploaded when you publish either a Universal Package
or a Pipeline Artifact. The syntax is similar to that of .gitignore .
.artifactignore is typically checked into your version control repository in the same directory from which you
upload your artifacts.
By using .artifactignore , you can avoid copying files into a staging directory before publishing your artifact. This
can help reduce the overall pipeline execution time.
**/*
!src/MyApp/bin/Release/**.*
In the above .artifactignore example, we instruct the universal package task and the pipeline artifact task to
ignore all files except the ones in the src/MyApp/bin/Release directory. To assure the proper execution,
.artifactignore file should be checked into the root of the repository.
Syntax
Refer to the Git documentation for .gitignore syntax. .artifactignore follows the same syntax with some minor
limitations.
IMPORTANT
The plus sign character + is not supported in URL paths as well as some of the builds semantic versioning metadata in
some packages types such as Maven.
Ignored by default
To reduce the chances of the entire .git folder being uploaded, we automatically ignore this directory. You can
unignore/include it by adding the following to your .artifactignore file:
!.git
What are feeds?
Azure DevOps Ser vices | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 | TFS
2017
Artifacts Feeds are organizational constructs that allow you to store, manage, and group your packages and control
who to share it with using feeds permissions.
Feeds are not package-type dependent. You can store all the following package types in a single feed: npm, NuGet,
Maven, Python, and Universal packages.
Project-scoped feeds vs. Organization-scoped feeds

Previously, all feeds were scoped to an organization, they could be viewed and accessed in the Azure Artifacts hub
from any project within an organization. With the introduction of public feeds, we also introduced project-scoped
feeds , which live inside the project that they were created in, and can only be seen when accessing the Azure
Artifacts hub within that project.
Only project-scoped feeds can be made public, see the following section on public feeds. Learn more about the
differences between project-scoped and organization-scoped feeds.T
NOTE
To access a feed in a different organization, a user must be given access to the project hosting that feed.
Public feeds
Public feeds can be used to share your packages publicly with anyone on the Internet. Users won't have to be a
member of your organization or your enterprise. They can access the packages even if they don't have an Azure
DevOps account.
Public feeds are project-scoped feeds and it will inherit the visibility settings of the hosting project.
There some important things to note regarding public feeds:
Public feeds can only be created inside of public projects.
Public feeds aren't intended as a replacement for existing registries of record (NuGet.org, npmjs.com, etc.).
Public feeds cannot have upstream sources.
Public users cannot currently download universal packages. All other package types are supported for public
access.
Create a feed
There are two types of feeds: project scoped and organization scoped feeds. All public feeds are project-scoped and
they inherit the visibility settings of the hosting project.
1. Go to Azure Ar tifacts .
2. Select Create Feed .
3. Give your feed a Name and choose its visibility , upstream sources and scope .
NOTE
Enabling upstream sources allow you to use your favorite OSS packages and gives you more protection against
outages and corrupted or compromised packages.
4. Select Create .
Azure Artifacts is installed by default for TFS 2017 customers. You must upgrade to TFS 2017 in order to use Azure
Artifacts. If this is the first time using your feed, you might be asked to assign a license
1. Go to Build & Release and select Packages .
2. Select + New feed .
3. Give your feed a Name , a Description , and set up who can read , who can contribute and if you want to
Include external packages .
NOTE
See Set feeds and views permissions to learn more about managing your feeds.
Restoring a deleted feed

If you accidentally delete a feed, Azure Artifacts provides a 30 days window to recover your feed to its original
state. After the 30 days, the feed will be deleted permanently. During the recovery window, the feed name will be
reserved, package download unavailable, and write access suspended for that feed.
You can view the feeds pending permanent deletion in your Feeds dropdown list under the Deleted Feeds tab.
1. Under Deleted feeds select your feed.
2. Select Feed Settings .
3. Select Restore Feed .

Permanently deleting a feed
A feed pending deletion will still use storage space. If you want to permanently delete your feed before the 30 days
period is up, you can do this from the deleted feeds settings.
1. Under Deleted feeds select your feed.
2. Select Permanently delete and confirm the deletion
Once the feed is permanently deleted, users won't be able to view or restore its packages. The feed name will be
available for reuse 15 minutes after the deletion.
Project-scoped feeds
Historically, all feeds used to be scoped to an organization. However, to enable public feeds and to become more
consistent with the rest of Azure DevOps, feeds created through the new create feed web UI will now be scoped to
a project.
New organization will automatically have one feed scoped to the organization and all subsequent feeds created will
be scoped to a project. All existing organization-scoped feeds will remain organization-scoped.
Understanding the difference between an organization-scoped feed

and a project-scoped feed
A project-scoped feed is scoped to a project instead of an organization.
Here are the main differences between the two feed types:
1. Visibility :
Project-scoped feeds will always use the visibility of the project. If a project is public, the feed is also
public and if the project is private, the feed is also private.
Organization-scoped feeds will always remain private.
2. Links :
The URL of a project-scoped feed includes the project.
Project-scoped feed: https://feeds.dev.azure.com/contoso/projectId/_apis/Packaging/Feeds
The URL of an organization-scoped feed doesn't include a project.
Organization-scoped feed: https://feeds.dev.azure.com/contoso/_apis/Packaging/Feeds
3. User interface :
All organization-scoped feeds will show up in the feed list of the Artifacts feed UI. To see a project-
scoped feed in the list you have to be navigated to the project the feed is scoped to.
All new feeds are recommended to be project-scoped. Creating a new feed through the create feed
web UI will create a project-scoped feed.
4. Connection :
When connecting to a private project scoped feed from an Azure DevOps pipeline that is in the same
organization but in a different project, the project that the feed is scoped to must allow access to the
other project's build service. The build service must also be separately added to the feed permissions,
regardless of the scope of the feed.
What can I do if I'm concerned about my project-scoped feed's visibility

There is an option to not allow public projects in an organization. It can be set under Security policies in
Organization Policy Settings.
If you're concerned that your project will be turned public in the future and you want your feed remain private, you
can use the organization-scoped feed that's automatically created when a new organization is created.
Alternatively, you can use the Create Feed API to manually create a new organization-scoped feed. You will have to
set the default permissions for the new feed manually either by using the Feed Permission API or the Artifacts feed
settings.
IMPORTANT
Creating new organization-scoped feeds is not recommended.
NOTE
If you want to share a package in your feed with all the users in your organization, you can promote that package to a
view and set its visibility to People in my organization . See Get started with feed views for more information.
IMPORTANT
If a user have permission to a specific view, and even if they don't have permission to the feed, they will still be able to access
and download packages through that view.
If you want to completely hide your packages, you must restrict both feeds and views permissions. See Feeds and views
permissions for more information.
What are Azure DevOps Services feed views?
Azure DevOps Ser vices | Azure DevOps Ser ver 2019 | TFS 2018 | TFS 2017
If you're familiar with the principles behind views, you can jump to the docs page to quickly start using them.
Views enable you to share subsets of the NuGet, npm, Maven, Python and Universal Packages package-versions in
your feed with consumers. A common use for views is to share package versions that have been tested, validated,
or deployed but hold back packages still under development and packages that didn't meet a quality bar.
Views and upstream sources

Views and upstream sources are designed to work together to make it easy to produce and consume packages at
enterprise scale.
In order for other Azure Artifacts feeds to use your feed as an upstream source, you must set your feed's view
visibility to people in your organization, or people in your Azure Active Directory (Azure AD) tenant, depending on
your scenario.
The @local view
All Azure DevOps Services feeds come with three views: @local , @prerelease , and @release . The latter two are
suggested views that you can rename or delete as desired. The @local view is a special view that's commonly
used in upstream sources.
@local contains all packages published directly to the feed (for example, by nuget push or npm publish ) and all
packages saved from upstream sources. If you don't use any other views, @local should be your default view. To
learn more about why @local exists, read the package graph doc.
Default view
Your Azure DevOps Services feed must have a default view. When the feed is created, the default view is @local .
The default view is used when other feeds add your feed as an upstream source. To learn more about why
upstream sources require the use of views, read the package graph doc.
Views cannot save packages from upstream sources
Views are read-only, which means that users connected to a view can only use packages that are published to the
feed and packages previously saved from upstream sources by users connected to the feed.
Using views to release packages

When creating packages in continuous integration and delivery scenarios, it's important to convey three pieces of
information: the nature of the change, the risk of the change, and the quality of the package.
Assess the nature and risk of changes
The nature and the risk of the change both pertain to the change itself, that is, what you set out to do, they're both
known at the outset of the work. You know if you're introducing new features, making updates to existing features,
or patching bugs; this is the nature of your change. And, you know if you're still making changes to the API surface
of your application; this is one facet of the risk of your change. Many NuGet users use Semantic Versioning
(SemVer) notation to convey these two pieces of information; SemVer is a widely used standard and does a good
job of communicating this information.
Determine and communicate quality
However, the quality of the package generally isn't known until validation, which comes after your change is built
and packaged. Because of this, it's not feasible to communicate the quality in the version number, which is
specified during packaging and before validation. There are workarounds to pre-validate (for example, by
consuming the build's DLLs directly before they're packaged; or, publishing packages to a "debug" or "CI" feed,
validating, and republishing to a "release" feed), but none that we've seen can truly guarantee that the built
package meets the correct quality standard.
Release views enable you to communicate the quality of a package after it's been validated. You create SemVer-
compliant packages in CI/CD that communicate the nature and risk of your changes using the package version,
then promote the package into a release view to show your consumers that it's of a certain quality (for example,
@prerelease , @release , etc.). So, a release view enables your consumers to see only the subset of versions of
each package that are tested, validated, and ready to go.
Use Azure Artifacts as a private PowerShell repository

Azure Artifacts provides an easy way to share your PowerShell scripts and books across your entire team or
company. By storing your PowerShell scripts in a private NuGet repository within Azure Artifacts, you can give
members of your team the ability to download or update them quickly using the command line.
NOTE
This guide assumes you've already set up Azure Artifacts. You can check out how to license the extension in the License Azure
Artifacts guide.
In this tutorial, you'll learn how to use Azure Artifacts as a private PowerShell repository that your team can
download and upload PowerShell modules to. You'll complete the following steps:
Create a Personal Access Token (PAT) to authenticate other services with Azure DevOps Services
Create a feed within Azure Artifacts that will be used to store your PowerShell modules
Create, package, and send a PowerShell module to your Azure Artifacts Feed
Connect to the feed from PowerShell to see and download your modules
Prerequisites
The NuGet CLI
An Azure DevOps Services account.
Create a PAT to get command-line access to Azure DevOps Services

The first step is to create a PAT through the Azure DevOps Services UI to authenticate your command-line with the
service.
1. Head to your organization in Azure DevOps Services: https://dev.azure.com/<org_name>
2. From your home page, open your profile. Go to your security details:
3. Create a personal access token.
4. Provide a name and an expiration date for your token and select your organization.
5. Select the scopes that this token will be authorized to access. You will only need Packaging: Read, write &
manage permissions for this tutorial but you can also add more privileges if you'd like to use this token for
other tasks.
6. When you're done, make sure to copy your token to a safe location, as you won't be able to view it
afterwards.
NOTE
To learn more about how to user personal access tokens, check out the Authenticate with PAT article.
Create the feed

A feed is a central repository that can store multiple packages of different types. To store our packages, the
PowerShell Modules in this scenario, we will need to create a new feed.
1. Navigate to Azure Ar tifacts from your organization.
2. Select Create Feed
3. In the dialog, provide a feed name and chose your visibility, scope and upstream sources.
4. Select Create .
Now that you've created a feed that will act as your PowerShell repository, let's create and package a PowerShell
module.
Creating, packaging, and sending a module

These next steps will be using a simple Get-Hello script that simply writes "Hello from my Azure DevOps Services
Package."
Create the file structure
Create a folder named Get-Hello . Within that folder create a Get-Hello.psm1 file:
|--- Get-Hello
|--- Get-Hello.psm1 // This will become our PowerShell Module
|--- Get-Hello.psd1 // This will become our module manifest
Create and populate the PowerShell module and module manifest
1. Paste the following script into your newly created Get-Hello.psm1 file:
Function Get-Hello{
Write-Host "Hello from my Azure DevOps Services Package."
}
2. Create the module manifest by running the following command in your Get-Hello directory path. This will
write the module manifest to your Get-Hello.psd1 file.
New-ModuleManifest -Path .\Get-Hello.psd1
3. Find the Nested Modules field in your Get-Hello.psd1 file and paste in the path to your Get-Hello.psm1
file. You may also need to define your RootModule when creating your own Module Manifests. To do so,
paste the following snippet in your Get-Hello.psd1
RootModule = 'Get-Hello.psm1'
4. The FunctionsToExport = @() section is meant to define the module's exported functions. This is simply a list
of all exported functions. Take following is an example from PowerShellGet.psd1 :
FunctionsToExport = @('Install-Module',
'Find-Module',
'Save-Module',
'Update-Module',
'Publish-Module',
'Get-InstalledModule',
'Uninstall-Module',
'Find-Command',
'Find-DscResource',
'Find-RoleCapability',
'Install-Script',
'Find-Script',
'Save-Script',
'Update-Script',
'Publish-Script',
'Get-InstalledScript',
'Uninstall-Script',
'Test-ScriptFileInfo',
'New-ScriptFileInfo',
'Update-ScriptFileInfo',
'Get-PSRepository',
'Set-PSRepository',
'Register-PSRepository',
'Unregister-PSRepository',
'Update-ModuleManifest')
5. It is also possible to define a list of files as part of your module. Just add this list under FileList=@() .
FileList = @('PSModule.psm1',
'PSGet.Format.ps1xml',
'PSGet.Resource.psd1')
Package and publish the module

We now have the module and the module manifest. We are ready to package it and publish it to our Azure Artifacts
feed.
1. In an elevated PowerShell prompt, run the following snippet:
nuget spec Get-Hello
The spec command will create a Get-Hello.nuspec file. This specifies the information that NuGet needs to
package our module. Few things to keep in mind here:
The version number on the Module Manifest and the .nuspec file must match.
By default, if we leave the sample dependencies, NuGet will install jQuery.
Here is the Get-Hello.nuspec file:
<?xml version="1.0"?>
<package >
<metadata>
<id>Get-Hello</id>
<version>1.0.0</version>
<authors>frantot</authors>
<owners>frantot</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>The module says hello to the user</description>
<releaseNotes>This is the newest I know of.</releaseNotes>
<copyright>Copyright 2019</copyright>
<tags>Francis Totten</tags>
<dependencies>
</dependencies>
</metadata>
</package>
2. Now that we have both the PowerShell module and the NuGet spec file, we are ready to to pack it and
publish it.
Package the module:
nuget pack Get-Hello.nuspec
Add the new package source to your NuGet configuration file:
nuget sources Add -Name "PowershellModules" -Source

"https://pkgs.dev.azure.com/<org_name>/_packaging/<feed_name>/nuget/v3/index.json" -username "
<user_name>" -password "<personal_access_token(PAT)>"
If you're still using the older visualstudio.com URLs, use the following command instead:
nuget sources Add -Name "PowershellModules" -Source

"https://<org_name>.pkgs.visualstudio.com/_packaging/<feed_name>/nuget/v3/index.json" -username "
<user_name>" -password "<personal_access_token_you_created>"
Publish the NuGet package to your feed:
nuget push -Source "PowershellModules" -ApiKey AzureDevOpsServices "your .nupkg path. eg: .\Get-
Hello.1.0.0.nupkg"
Our PowerShell module is now available in our feed.

NOTE
Your NuGet.config file is located at %appdata%\NuGet\NuGet.Config for Windows, and at
~/.config/NuGet/NuGet.Config or ~/.nuget/NuGet/NuGet.Config for Mac/Linux (depending on the OS distribution).
Connecting to the feed as a PowerShell repo

We now have a private repository within Azure Artifacts that we can push our PowerShell modules to and we have
a module that we can install. In the next step, we will connect to our new Azure Artifacts feed so we can publish our
own modules as well as install other modules published by members on our team.
1. Open an elevated PowerShell prompt
2. Set up authentication to access Azure artifact feeds. Replace the placeholders with your personal access
token and email:
$patToken = "YOUR PERSONAL ACCESS TOKEN" | ConvertTo-SecureString -AsPlainText -Force
$credsAzureDevopsServices = New-Object System.Management.Automation.PSCredential("YOUR EMAIL",

$patToken)
3. Register your PowerShell repository. The SourceLocation link can also be found by selecting Connect to
Feed then NuGet.exe from the feed's page in Azure Artifacts.
Register-PSRepository -Name "PowershellAzureDevopsServices" -SourceLocation

"https://pkgs.dev.azure.com/<org_name>/<project_name>/_packaging/<feed_name>/nuget/v2" -PublishLocation
"https://pkgs.dev.azure.com/<org_name>/<project_name>/_packaging/<feed_name>/nuget/v2" -
InstallationPolicy Trusted -Credential $credsAzureDevopsServices
IMPORTANT
PowerShell does not support Version 3 of NuGet.
If you're still using the older visualstudio.com URLs, use the following command instead:
Register-PSRepository -Name "PowershellAzureDevopsServices" -SourceLocation

"https://<org_name>.pkgs.visualstudio.com/<project_name>/_packaging/<feed_name>/nuget/v2" -
PublishLocation
"https://<org_name>.pkgs.visualstudio.com/<project_name>/_packaging/<feed_name>/nuget/v2" -
InstallationPolicy Trusted -Credential $credsAzureDevopsServices
TIP
Certain versions of PowerShell requires restarting a new session after executing Register-PSRepository cmdlet to
avoid the Unable to resolve package source warning.
4. To confirm that the repository was registered successfully run the Get-PSRepository cmdlet. This command
gets all module repositories registered for the current user:
Get-PSRepository
5. Find modules in our repository:
Find-Module -Repository PowershellAzureDevopsServices
Our Get-Hello module should be one of the entries in the previous cmdlet's return message. To install it,
run the following command:
Install-Module -Name Get-Hello -Repository PowershellAzureDevopsServices
You can check for your module by running the following command:
Get-Module -ListAvailable Get-Hello
We now have our private PowerShell repository to publish and download our packages to and from our feed and
best of all, available to everyone on our team.
Credit
Credit to this article on Medium that was used as a source for this tutorial.
Share your packages publicly
Azure Artifacts provides an easy way to share packages to users outside your organization using public feeds.
Packages that are stored in public feeds can be restored, installed, or consumed by anyone on the Internet.
NOTE
Public feeds are project-scoped feeds that live inside a public project. You cannot convert an existing organization-scoped
feed into a project-scoped feed or a public feed.
To learn more about feeds and their scopes, check out our feeds documentation.
Prerequisites
A public project. If you don't have one, create one now
Create a feed
1. Go to Azure Ar tifacts in a public project:
2. Select + New public feed :

3. In the dialog box:
Give the feed a name.
Select Create feed .
Publish your packages

Now that you have a public feed, it's time to populate it with packages!
IMPORTANT
Public feeds cannot store Universal Packages.
If you're publishing using NuGet or Dotnet and you're using a credential provider to authenticate, public feeds
require you to use the new credential provider instead of the older CredentialProvider.VSS.exe . You can learn more
about the new credential provider, including install and setup instructions in the artifacts-credprovider GitHub repo.
From the command line
The following articles are quick guides that show you how to set up authentication and publish packages to your
public feed from the command line. You can skip the "Create a feed" step in the following guides.
Quickstart - Push and consume NuGet packages
Quickstart - Push and consume npm packages
Quickstart - Push and consume Maven packages
Quickstart - Push and consume Python packages
From Azure Pipelines
The following articles cover publishing packages to feeds from builds within Azure Pipelines:
Publish NuGet packages from Azure Pipelines
Publish npm packages from Azure Pipelines
Setting up Maven and Azure Pipelines
Publish Python packages from Azure Pipelines
Share your packages

NOTE
Public feeds aren't intended to be a replacement for registries of record like NuGet.org or npmjs.com, and public feeds
cannot have upstream sources.
To start sharing your packages, simply post or send your feed URL wherever you wish:
Sample feed URL: https://dev.azure.com/<org_name>/<project_name>/_packaging?_a=feed&feed=<feed_name>
As long as your project is public, anonymous and guest users will be greeted by the feed UX where they can see the
available packages and learn how to consume them. Anonymous users will not have access to all features. E.g.
Creating new feeds or accessing the recycle bin.
You can also share individual packages with badges which look like the example below.
IMPORTANT
Package badges can only be created and shared for released versions of packages; the criteria for what is considered a
released version depends on the protocol type. Pre-released versions will not be displayed in badges, instead the badge will
show the latest release version.
Protect your open-source software packages with
upstream sources
Upstream sources enable you to manage your product's OSS dependencies in a single feed. Using upstream
sources makes it easy to use your favorite OSS packages, and can also give you additional protection against
outages and corrupted or compromised packages. You can also publish private dependencies in the same feed that
manages your OSS dependencies. Read all about upstream sources and their benefits.
This tutorial covers how to upgrade an existing project that uses OSS packages from public registries like
nuget.org, npmjs.com, etc. to instead get those dependencies from an Azure Artifacts feed with upstream sources.
In this tutorial, you will:
Create a new feed using upstream sources
Replace the public registry in your configuration files
Run an initial package restore to populate your feed
Check your feed to see the saved copy of everything you used from the public registry
Create a feed with upstream sources enabled

1. Navigate to Azure Ar tifacts :
1. Select + New feed :
1. In the dialog, provide a feed name and click Create.

1. Navigate to the Packages page:
2. Select + New feed :

3. In the dialog:
Choose who can read and contribute (or update) packages in your feed.
Select Use packages from public sources through this feed
When you're done, choose Create .
Now that you've created the feed that we will use to store your packages, you will update your configuration files to
point to the newly created feed.
Replace the public registry in configuration files with the Azure Artifacts
feed
The next step is to update your configuration file to point to the new Azure Artifacts feed instead of the public
registry. There are two steps to achieve this:
1. Get your feed's URL
2. Update the configuration file with the feed URL
npm
NuGet
1. From your Packages page, click Connect to Feed
2. Select the npm tab under the npm header
NOTE
If you don't have npm or the ar tifacts-credhelper installed, select Get the tools in the top right and follow steps 1 and
2 to get the tools to continue.
3. Follow the instructions under Project setup :
1. From your Packages page, click Connect to Feed

2. Copy the "registry" text:
After you've got the feed URL, create a new text file named .npmrc in the root of your project (in the same folder as
your package.json file). Open your new .npmrc file and paste the text that you copied in step 2 above.
Run an initial package restore to populate your feed

Now that you have upstream packages set up, you'll need to run an initial package restore to populate your new
feed with the upstream packages.
The basic steps are to clear your local package cache and then do a clean install of all the packages used by the
project so that Azure Artifacts can save them from the upstream source.
npm
NuGet
Remove the node_modules folder in your project (find out more about the node_modules folder), and rerun:
npm install --force
The -force option is to ensure the cache is bypassed.
The instructions above show the simplest way to populate your feed. In larger projects, you can also consider
setting up a continuous integration (CI) build that has a clean cache on each build run. This build will then save any
new packages from upstream sources as they're used.
Check your feed to see the saved copy of everything you used from the
public registry
Navigate to the feed you created in Step 1. This feed should now be populated with the packages that are used in
your project. The Source field contains the public registry, or other upstream source, that you were using before
completing this tutorial.
Use the prerelease and release views to publish your
packages
Azure DevOps Ser vices | Azure DevOps Ser ver 2019

Feeds are containers that allow users to group packages and control who can access them by modifying the feed
permissions.
A feed view on the other hand is a way to enable users to share some packages while keeping others private. Views
filter the feed to a subset of packages that meet criteria defined by that view.
There are 3 types of views: @local , @Prerelease and @Release . The latter two are suggested views that you can
rename or delete as desired. Those views contain a subset of the feed's packages that have been promoted into
that specific view. All views currently support NuGet, npm, Maven, Python, and Universal packages.
If you've never used feed views, read more about why and how they're useful for package continuous integration
and delivery before getting started.
Get started with feed views

By default, every feed has three types of views: local , Prerelease , and Release view.
Promoting to a prerelease or release view
To promote a package-version:
1. Select the package
2. Select the Promote button
3. Select the view to promote to and select Promote
Promoting a package using the REST API
In addition to using the user interface in Azure Artifacts, you can also promote a package to a view using the REST
API. Azure Artifacts currently supports the following package types: NuGet, Python, npm, Maven (limited
operations), and Universal packages.
Promote a NuGet package :
Example:
PATCH
https://pkgs.dev.azure.com/{organization}/{project}/_apis/packaging/feeds/{feedId}/nuget/packages/{packageName
}/versions/{packageVersion}?api-version=5.1-preview.1
See NuGet - Update Package Version for more details.

Promote an npm package :
Example:
PATCH
https://pkgs.dev.azure.com/{organization}/_apis/packaging/feeds/{feedId}/npm/{packageName}/versions/{packageVe
rsion}?api-version=5.1-preview.1
See Npm - Update Package for more details.

Promote a Python package :
Example:
PATCH
https://pkgs.dev.azure.com/{organization}/{project}/_apis/packaging/feeds/{feedId}/pypi/packages/{packageName}
/versions/{packageVersion}?api-version=5.1-preview.1
See Python - Update Package Version for more details.

Promote a Universal package :
Example:
PATCH
https://pkgs.dev.azure.com/{organization}/_apis/packaging/feeds/{feedId}/upack/packages/{packageName}/versions
/{packageVersion}?api-version=5.1-preview.1
See Universal - Update Package Version for more details.

Keep in mind that you cannot publish a package directly to a view (for example,
nuget.exe publish -Source ...feed@view/nuget/... ). Instead, you should publish the package to your feed then
promote it to a view.
NOTE
Package demotion is not supported currently. If you want this feature to be added to future releases, please feel free to
Suggest a feature on our Azure DevOps Developer Community.
Managing views
You can create your own views or rename and delete existing ones in the feed settings dialog.
With your feed selected, select the gear icon (on the right side of the page).
In the feed settings view:

Select Views
Make your changes (Add view, Edit, or Delete)
Select Ok
Help and support

Get advice on Stack Overflow
Get support via our Support page
Follow us on Twitter @AzureDevOps
Migrate your packages to Azure Artifacts
Using the AzureArtifactsPackageMigration PowerShell module, you can easily migrate your NuGet packages from
MyGet. Future development will support migration from other packaging solutions and package types.
NOTE
This does not remove the packages from your current package feed. It copies them to your Azure Artifacts feed and will not
interfere with use of the source feed.
Prerequisites
The NuGet CLI
An Azure DevOps Services account
An Azure Artifacts feed
A PAT. A Personal Access Token to authenticate your feed.
PowerShell. The AzureArtifactsPackageMigration module works with latest versions of PowerShell. With
Windows, you need at least version 5.1. For Linux or Mac, you will need at least version 6.
Install and import the module

1. In Windows, open a PowerShell Window, form Mac or Linux, open a terminal and run the pwsh command to
start PowerShell.
2. Run the following commands to install the module and import it into your current session.
Install-Module -Name AzureArtifactsPackageMigration -Scope CurrentUser -Force

Import-Module -Name AzureArtifactsPackageMigration
Alternatively, you can download it from the GitHub page.
Collect URLs to transfer packages

To migrate your packages, you will need the index URL to your source, and destination feeds.
Get Azure Artifacts Index URL
You can easily copy the destination URL from the Connect to feed dialog box.
Get Index URL from MyGet
1. Log into your MyGet Account and navigate to the feed you want to migrate.
2. Select Feed Details
3. Copy the NuGet V3 feed URL
Run the migration

If your source feed is not public, you will need to create a SecureString to use as your password to access it.
1. You can skip this step if your source feed is public.
$password = ConvertTo-SecureString -String '<your password here>' -AsPlainText -Force
2. Using the source and destination index URLs you collected earlier, run the following command based on your
need. To have less output, simply remove the -Verbose switch from the command.
# Migrate packages from a private source feed.

Move-MyGetNuGetPackages -SourceIndexUrl '<your source index url here>' -DestinationIndexUrl '<your
destination index url here>' -DestinationPAT '<your destination PAT string here>' -DestinationFeedName '<your
destination feed name>' -SourceUsername '<username for source feed>' -SourcePassword $password -Verbose
# Migrate packages from a public source feed.
Move-MyGetNuGetPackages -SourceIndexUrl '<your source index url here>' -DestinationIndexUrl '<your
destination index url here>' -DestinationPAT '<your destination PAT string here>' -DestinationFeedName '<your
destination feed name>' -Verbose
3. After a successful migration, you should see output with the number of packages copied.
NOTE
This module uses NuGet and your local environment to migrate packages. Depending on the size and amount of packages
you are moving, this could take up to an hour or more.
Next Steps
For more information about NuGet packages in Azure Artifacts, see the Get Started guide
Open source
This module is open source on GitHub. Feedback and contributions are welcome.
Move your packages to the cloud
Azure DevOps Ser vices | TFS 2018 | TFS 2017

Azure DevOps Services provides hosted NuGet feeds as a service. If you're using NuGet packages as a part of your
continuous delivery flow, Azure Artifacts can eliminate your dependencies on on-premises file shares and hosted
instances of NuGet.Server. Azure Artifacts works with any CI system that supports authenticated NuGet feeds. This
walkthrough assumes that you're using Azure DevOps Services Team Build (not XAML Build).
Before you start

Azure DevOps Services NuGet service provides a number of benefits compared to file shares. However, some of
these benefits may require changes to your existing workflows.
Indexing: Azure DevOps Services maintains an index of all the packages in each feed, which enables fast
nuget list operations. List operations on your file shares require the client to open every nupkg and examine
the nuspec for metadata unless your file share has been configured to provide an index that the NuGet client
understands.
Immutability: A package version (e.g. MyPackage.1.0.0.0.nupkg ) can only be pushed to a feed once. This
ensures that any dependencies on that version are guaranteed to remain valid. However, if you have workflows
that publish packages with newer binaries without changing the version number, those workflows will break
when moved to Azure DevOps Services NuGet feeds. Learn more about Immutability in Azure DevOps Services.
Well-formedness: Azure DevOps Services validates all pushed packages to ensure they're well-formed. This
prevents invalid packages from entering your development and build environments. However, any workflow
that publishes malformed packages will break when moving to Azure DevOps Services NuGet feeds.
NuGet 4.8+ is recommended
NOTE
The Azure Artifacts service recommends NuGet 4.8.2 or later. However, Azure Artifacts also supports legacy NuGet 2.x clients.
For a complete list of the latest clients, see the NuGet distribution page.
Authentication and authorization

If you're using Active Directory-backed file shares, you and your on-prem build agents are likely authenticating
automatically using Windows NTLM. Moving your packages to Azure DevOps Services will require a few changes:
Authentication: You need to provide the NuGet client with credentials in order to restore and push packages.
Visual Studio 2015 users : Credential acquisition happens automatically, as long as you've updated the
NuGet Package Manager extension to version 3.3 or higher by going to the Tools menu and using the
Extensions and Updates window.
nuget.exe 3.x users : Credential acquisition happens automatically after you install the Azure DevOps
Services Credential Provider.
Authorization: Ensure that any principal (user, service organization, group, etc.) that needs access to your
packages has the appropriate permissions. See the permissions section for details.
Move your packages

Moving your packages to the cloud is a 4-step process:
1. Inventory your existing package sources
2. Make a plan for permissions
3. Set up your feeds
4. Use your feeds
Inventory your existing package sources
Before making any configuration changes, find your existing NuGet file shares by checking:
Any nuget.config files in your codebase, likely in the same folder as your .sln file
The global nuget.config file at
Command Prompt: %APPDATA%\NuGet\NuGet.Config
PowerShell: $env:APPDATA\NuGet\NuGet.Config
Look for any lines with a UNC path (like <add key="SMBNuGetServer" value="\\server\share\NuGet" /> ) and note the
path. You'll use the list of paths in the migrate section later.
Make a plan for permissions
When setting up your new feeds, you can either:
Set up your feed permissions to match your existing file share permissions
Align your feed permissions with existing Azure DevOps Services teams and groups
If you want to match your existing file share permissions, note the permissions on each share that contains
packages. Specifically, note the principals with:
Full control
Modify or write
Read & execute , List folder contents , or Read
Set up your feeds
Now that you've inventoried your existing package sources, it's time to set up the feeds that will replace them. For
this walkthrough, we'll assume a 1:1 mapping of feeds to SMB shares.
Create your feeds
For each SMB share, create a feed using the instructions here. In the create dialog:
Use the name of the SMB share folder as the Feed name
Leave the defaults for Who can read and Who can contribute
For each feed you've created, edit the feed and set permissions. There are a set of common identities that you
should consider when setting up feed permissions.
If you've chosen to set up your new feed permissions to match your existing file share permissions, use the
following table to give your principals the appropriate group membership:
SM B P ERM ISSIO N F EED GRO UP
Full control Owners
Modify, Write Contributors
Read & execute, List folder contents, Read Readers
Use your feeds

Get your feed's NuGet source URL
For each feed, click the Connect to feed button and copy the Source URL in the Connect with NuGet section. Use
the Source URL in the migrate and update sections.
Migrate your packages
Once you've set up your feeds, you can do a bulk push from each SMB share to its corresponding feed. To do so:
1. If you haven't already, open a PowerShell window in the repo where you installed the Azure DevOps Services
NuGet tools and run init.ps1 . This sets up your environment to allow you to work with nuget.exe and Team
Service's NuGet feeds.
2. For each share, push all packages in the share to the new feed:
nuget push {your package path}\*.nupkg -Source {your NuGet package source URL} -ApiKey Azure DevOps Services
For larger teams, you should consider marking each share as read-only before doing the nuget push operation to
ensure no one adds or updates packages during your migration.
Update your NuGet configuration
Now, return to each of the nuget.config files you found in the inventory section. For each share, find the
corresponding <add key="SMBNuGetServer" value="\\server\share\NuGet" /> and replace the value with the new
feed's source URL.
Add the Azure DevOps Services NuGet tools to your repo
The Azure DevOps Services NuGet bootstrap package can automate the process of acquiring the right NuGet tools
and credentials to use feeds. This is especially helpful for users of Visual Studio 2013 (or earlier) or NuGet 2.x,
which don't have built-in support for Azure DevOps Services auth.
Integrate with your builds
Update your builds to ensure they have the right credentials to consume and publish packages in feeds. See the
how-tos for restoring and publishing packages in Team Build.
Secure and share packages using feed permissions

The packages you host in Azure Artifacts are stored in a feed . Setting permissions on the feed allows you to
share your packages with as many or as few people as your scenario requires.
Feed permissions overview

Feeds have four levels of access: Owners, Contributors, Collaborators, and Readers. Owners can add any type of
identity-individuals, teams, and groups-to any access level.
P ERM ISSIO N REA DER C O L L A B O RATO R C O N T RIB UTO R O W N ER
List and ✓ ✓ ✓ ✓
restore/install
packages
Save packages from ✓ ✓ ✓

upstream sources
Push packages ✓ ✓
Unlist/deprecate ✓ ✓
packages
Promote a package ✓ ✓
to a view
Delete/unpublish ✓
package
Edit feed permissions ✓
By default, the Project Collection Build Service is a Contributor and your project team is a Reader.
NOTE
To access a feed in a different organization, a user must be given access to the project hosting that feed.
Azure Artifacts settings

Azure Artifacts settings allow you to specify who can create and administer feeds.
By default, everyone in the same organization have the permissions to create feeds. A user who creates a feed is
both an owner and an administrator of that feed.
1. Any user in the organization is allowed to create feeds.

2. Only feed administrators and users or groups specified in the text box 2 are allowed to create feeds. You
can specify a feed administrator by adding users or groups in the who can administer feeds section.
3. Users or groups added here are allowed to administer any feed in the organization.
NOTE
It's very important to understand the difference between feed, project, and project collection administrators. A feed
administrator can perform all operations on the feed (edit feed permissions, delete packages, promote packages, etc.).
A project administrator on the other hand has permissions to administer all aspects of teams and project (delete team
project, update project visibility, manage test environments etc.).
Project Collection Administrators are granted all collection-level permissions to manage resources for projects and
project collections (add and delete projects, trigger events, manage build resources and audit streams etc.).
Adding users/groups permissions to a feed

Editing permissions for a feed
Select Permissions .
Select Add users/groups .
Add users and/or groups and choose their access role.
When you're done, select Save .

In the edit feed dialog:
Choose to make each person or team an Owner, Contributor, Collaborator, or Reader.
When you're done, select Save .
Understanding feeds and views permissions

Feeds are containers that allow users to group packages and control who can access them by modifying the feed
permissions.
A feed view on the other hand is a way to enable users to share some packages while keeping others private. A
common scenario for using a feed view is when a team shares a package version that has already been tested
and validated but keeps packages that are still under development from being viewed.
By default, there are 3 views in a feed: @local , @prerelease , and @release . The latter two are suggested views
that you can rename or delete as desired.
The @local view is the default view and it includes all the packages that were published directly to the feed as
well as all the packages that were saved from the upstream sources.
IMPORTANT
If a user have permission to a specific view, and even if they don't have permission to the feed, they will still be able to
access and download packages through that view. If you want to completely hide your packages, you must restrict both
feeds and views permissions.
To restrict access to your feed, simply select a user or group from the permission table in your Feed Settings and
select Delete . You can restrict access to a view by changing its visibility to specific people as shown below.
After restricting your view's visibility to specific people , the access permissions column should reflect your
changes.
IMPORTANT
A very important concept to keep in mind is that views inherit their permissions from their parent feed. Setting view
permissions to Specific people without specifying users or groups will cause the view permissions to default back to
their parent feed permissions.
Package permissions in Azure Pipelines

To use packages from a feed in Azure Pipelines, the appropriate build identity must have permission to your feed.
By default, the Project Collection Build Ser vice is a Contributor. If you've changed your builds to run at
project scope, you'll need to add the project-level build identity as a Reader or Contributor, as desired. The
project-level build identity is named as follows:
[Project name] Build Service ([Organization name]) (e.g. FabrikamFiber Build Service (codesharing-demo))
You can also use the Allow project-scoped builds feature if you would like to automatically set up permissions
for your project-scoped build identity.
1. With your feed selected, select the gear icon to access the Feed settings .
2. Select Permissions .
3. Select the ellipsis on the right and select Allow project-scoped builds from the drop down menu.
NOTE
If you want your pipelines to use a package from a feed in a different project, you must set up the other project to grant
read/write access to the build service in addition to setting up the appropriate feed permissions.
Sharing packages with everyone in your organization

If you want to make the packages in a feed available to all users in your organization, create or select a view that
contains the packages you want to share and ensure its visibility is set to People in my organization .
Sharing packages publicly with anonymous users

You can also make your packages available to anonymous users with limited access by creating a public feed.
Upstream sources
2017
Check the (availability note) to ensure compatibility.
Upstream sources enable you to use a single feed to store both the packages you produce and the packages you
consume from "remote feeds": both public feeds (for example, npmjs.com, NuGet.org, Maven Central, and PyPI)
and authenticated feeds (that is, other Azure DevOps Services feeds in your organization or in organizations in
your Azure Active Directory (Azure AD) tenant). Once you've enabled an upstream source, any user connected to
your feed can install a package from the remote feed, and your feed will save a copy.
Already familiar with the concepts and want to jump right in? Start with these how-tos:
How-to: Set up upstream sources
Use nuget.org as an upstream
Use npmjs.com as an upstream
Use Maven Central as an upstream
NOTE
Custom upstream sources are currently only supported for npm.
Benefits of upstream sources

Upstream sources enable you to manage all of your product's dependencies in a single feed. We recommend
publishing all of the packages for a given product to that product's feed, and managing that product's
dependencies from remote feeds in the same feed, via upstream sources. This setup has a few benefits:
Simplicity: your NuGet.config, .npmrc, or settings.xml contains exactly one feed (your feed).
Determinism: your feed resolves package requests in order, so rebuilding the same codebase at the same
commit or changeset uses the same set of packages
Provenance: your feed knows the provenance of packages it saved via upstream sources, so you can verify
that you're using the original package, not a custom, or malicious copy published to your feed
Peace of mind: packages used via upstream sources are guaranteed to be saved in the feed on first use; if
the upstream source is disabled/removed, or the remote feed goes down or deletes a package you depend
on, you can continue to develop and build
Best practices: feed consumers

To take full advantage of the benefits of upstream sources as a consumer of another feed, consider applying the
following best practices to your project.
Use a single feed on the client
In order for your feed to provide deterministic restore, it's important to ensure that your package feed
configuration file—your .npmrc or nuget.config—references only your Azure Artifacts feed with upstream
sources enabled. For NuGet, the <packageSources> section should look like:
<packageSources>
<clear />
<add key="FabrikamFiber"
value="https://pkgs.dev.azure.com/fabrikam/_packaging/FabrikamFiber/nuget/v3/index.json" />
</packageSources>
NOTE
The <clear /> tag is required because NuGet composes several configuration files to determine the full set of options to
use. <clear /> tells NuGet to ignore all other <packageSources> defined in higher-level configuration files.
For npm, you should have only one registry line, like:
registry=https://pkgs.dev.azure.com/fabrikam/_packaging/FabrikamFiber/npm/registry/
always-auth=true
Order your upstream sources intentionally

If you only use public upstream sources (for example, nuget.org or npmjs.com), the order of your upstream
sources is irrelevant. Requests to the feed will follow the search order.
If you use multiple Azure DevOps Services upstream sources, or a mixture of public and Azure DevOps Services
upstream sources, their order is taken into account in step 3 of the search order. In that case, we recommend
putting the public upstream sources first. This ensures that you look for OSS packages from the public repos
before checking any Azure DevOps Services upstream sources, which could contain modified versions of public
packages.
In rare cases, some organizations choose to modify OSS packages to fix security issues, to add functionality, or to
satisfy requirements that the package is built from scratch internally, rather than consumed directly from the
public repository. If your organization does this, put the Azure DevOps Services upstream source that contains
these modified OSS packages before the public upstream sources to ensure you use your organization's
modified versions.
Use the suggested default view
Upstream sources to Azure DevOps Services feeds require you to select a view of the remote feed when you add
it as an upstream source. This prevents your upstream sources from creating a cycle, and it requires and
encourages your upstream feed to provide you with a complete package graph. In general, the feed owner
should select the correct default view, as the view communicates which packages and versions the producer
wants consumers to use.
Best practices: feed owners/package producers

To make your feed easily usable as an upstream source to other feeds, consider applying the following best
practices to your feed.
When in doubt, @local is your default view
If you don't use views, the @local view should be your default view (and is the default view on all newly created
feeds). @local contains all packages uploaded/pushed/published to the feed from a package client (for example,
nuget.exe) and all packages saved from any upstream source. @local, like all views, does not include packages
that are available in the feed's upstream sources but have never been saved into the feed.
If you do use views to communicate a release quality, you can set the default view to whichever view contains
the packages you want to make available to your consumers.
Provide a complete graph
Because your consumers require a complete graph to successfully install and consume your package, you
should ensure that your default view contains one. This is most easily done by connecting to the feed's default
view (NuGet, npm) and installing the package you wish to share. You may need to do this once connected to the
feed (instead of the feed@view). If the package installs correctly while you're connected to the default view, all of
its dependencies are in the view.
Determining the package to use: search order

For package managers that support multiple feeds (like NuGet and Maven), the order in which feeds are
consulted is sometimes unclear or non-deterministic (for example in NuGet, parallel requests are made to all
feeds in the config file and the first response wins). Upstream sources prevent this non-determinism by
searching the feed and its upstream sources using the following order:
1. Packages pushed to the feed
2. Packages saved via an upstream source
3. Packages available via upstream sources: each upstream is searched in the order it's listed in the feed's
configuration
To take advantage of the determinism provided by upstream sources, you should ensure that your client's
configuration file only references your product feed, and not any other feeds like the public sources.
Saving packages from upstream sources: continuity

When you enable an upstream source, packages installed from the upstream source via the feed will
automatically be saved in the feed. These packages could be installed directly from the upstream (for example,
npm install express ) or they could be installed as part of dependency resolution (for example, the install of
express would also save dependencies like accepts ).
Saving can improve download performance and save network bandwidth, esp. for TFS servers located on
internal networks.
Overriding a package from an upstream source

You can't publish any package-version that already exists in any upstream source enabled on your feed. For
instance, if the nuget.org upstream source is enabled you cannot publish Newtonsoft.Json 10.0.3 because that
same package-version is already present on nuget.org.
If you must push a package-version that already exists on one of your upstream sources, you must disable the
upstream source, push your package, then re-enable the upstream source. Note that you can only push a
package-version that wasn't previously saved from the upstream, because saved packages remain in the feed
even if the upstream source is disabled or removed. See the immutability doc for more info.
Metadata cached from upstream sources
When you configure an upstream source and begin to query it through your feed, the feed will keep a cache of
the metadata that you queried (most often, the package you asked for and its available versions) for 24 hours.
There is a 3-6 hour delay between when a package is pushed to an upstream source and when it is available for
download by your feed. This delay depends on job timing and package data propagation.
NOTE
To force a refresh on the cached version of your package, use the NuGet - download package HTTP request with a HEAD
call instead of GET .
Upstream health
If a feed has failing upstream sources, the metadata no longer can be refreshed for packages of the same
protocol. Follow the steps below to view the health status of the upstream source:
With your feed selected, select the gear icon to access your Feed settings , then select Upstream sources
in your feed settings UI.
If there are any failing upstream sources, the Artifacts UI shows a warning message to notify that issues have
been detected and manual action may be needed. Upstream setting page will show which one of the upstream
sources is failing and by clicking the failing source, users can find the reason for the failure and instructions on
how to solve it.
Offline upstream sources

Upstream sources protect you and your CI/CD infrastructure from outages in public sources. That protection
works for both short and long outages.
For outages lasting less than 12 hours, you can continue to use the feed as normal thanks to the metadata cache.
For outages lasting more than 12 hours, which are infrequent, you will experience issues listing and restoring
packages, even if those packages have been installed into the feed. In these scenarios, you can delete either the
offline upstream or all upstream sources of the affected package type and continue developing and building as
normal. If/when the upstream source returns, just re-add it.
Legacy upstream source information

Older Azure Artifacts feeds ("legacy feeds") use an older version of the npmjs.com upstream source and are also
unable to use the nuget.org upstream source.
Configure upstream sources
Upstream sources enable you to use a single feed to store both the packages you produce and the packages you
consume from "remote feeds": both public feeds (e.g. npmjs.com and NuGet.org) and authenticated feeds (i.e.
other Azure DevOps Services feeds in your organization or Azure Active Directory (Azure AD) tenant). Once you've
enabled an upstream source, any user connected to your feed can install a package from the remote feed, and your
feed will save a copy.
For more in-depth information on the concepts and best practices regarding upstream sources, check out the
upstream sources concepts documentation.
Create a new feed that uses upstream sources

Navigate to the Packages page and select "New Feed".
Underneath Upstream Sources, select Use packages from public sources through this feed.
Selecting this option now means your feed will be configured to find and use packages from all of the public
upstream sources (nuget.org (NuGet), npmjs.org (npm), PyPI (Python), and Maven Central (Maven)) without
having to include those package repositories in any of your settings or configuration files.
IMPORTANT
Maven snapshot artifacts are not currently supported in upstream sources.
Add public upstream sources to an existing feed

1. From your feed page, go to Feed settings by clicking the gear icon
2. On the Upstream sources tab, if you don't have any upstream sources you'll see a dialog where you can
choose Add upstream source. If you already have it, you can select Add upstream source in the top menu.
3. In the Add a new upstream source dialog, choose Public source
NOTE
Public sources may be greyed out if you chose to include public upstream sources when creating the feed and they
already exist in your upstream sources.
4. For public sources, choose npmjs , NuGet Galler y , PyPI , or Maven Central
NOTE
You can also configure a custom upstream source for public repositories other than those listed above. Custom
upstream sources are only available for npm .
Add an Azure Artifacts feed in your organization as an upstream source

2. On the Upstream sources tab, if you don't have any upstream sources you will see the below dialog where
you can choose Add upstream source. If you already have it, you can select Add upstream source in the top
menu.
3. In the Add a new upstream source dialog, choose Azure Artifacts feed in this organization
4. Select the feed you would like to configure as an upstream source, and the other fields will populate
automatically.
5. Select the package types you want to use and click Add.
Add an Azure Artifacts feed in a different organization within your

Azure AD tenant as an upstream source
IMPORTANT
The Universal Packages protocol currently only supports upstream sources in the same Azure DevOps organization.
2. On the Upstream sources tab, if you don't have any upstream sources you will see the below dialog where
you can choose Add upstream source. If you already have it, you can select Add upstream source in the top
menu.
3. In the Add a new upstream source dialog, choose Azure Artifacts feed in another organization
4. Enter the Azure DevOps Ser vices feed locator , this is just azure-feed:// followed by the organization
name, project name, feed name, and the view that is shared. For example:
azure-feed://myOrg/myProject/myFeed@local
5. Select the package types you want to use and click Add.
Consuming NuGet packages from upstream sources

Now you can open Visual Studio and install packages from the upstream sources you've configured. As covered
already on the consume NuGet packages documentation, You'll need to use these instructions to install packages
from the upstream:
1. On the upstream source (e.g. nuget.org), copy the Install-Package command
2. In Visual Studio, open the Package Manager Console from Tools > NuGet Package Manager
3. Paste the Install-Package command into the Package Manager Console and run it
Remember that you must be a Collaborator, Contributor, or Owner to install new packages from the upstream, as a
copy of each upstream package you use is saved to the feed on first use. Packages already saved from an upstream
source can be used by Readers.
Consuming npm packages from upstream sources

Now you can open your favorite shell and install packages from the upstream sources you’ve configured. Just run:
npm install --save <package>
See the npm install docs for more details.

Remember that you must be a Collaborator, Contributor, or Owner to install new packages from the upstream, as a
copy of each upstream package you use is saved to the feed on first use. Packages already saved from an upstream
source can be used by Readers.
FAQs
What are views?
Views are covered in the views concepts page, but simply put it's the set of packages that the feed owner believes
should be consumed and has chosen to release by default.
Why can't I see the feed I want to configure as an upstream?
It could be the case that the feed owner has not shared a view to be available for upstreaming.
Share your NuGet, npm, and Maven packages from
Azure DevOps Services with badges

You can share your packages anywhere you can share an image with badges. You can put a badge directly into your
project's home page in Azure DevOps Services or in any Markdown/README file so readers can easily discover
and consume your package.
Example NuGet package badge:
NOTE
Package badges can only be created and shared for released versions of packages; the criteria for what is considered a
released version depends on the protocol type. Prereleased versions will not be displayed in badges, instead the badge will
show the latest release version.
Enable package sharing

To start sharing your Azure DevOps Services-hosted packages with badges you'll first have to turn on Package
sharing in your feed settings.
Only feed administrators can edit the feed.
1. Go to your Feed settings page by clicking on the gear icon from your feed page:
2. Find the Package sharing section and select Enable package badges.
This will enable the Create badge button for every package in that feed.
Create badge
You can create a badge for any package that is in a feed with package sharing enabled. You can only create a badge
for the latest version of each package.
1. Go to your package in Azure DevOps Services and click the Create badge option.
2. Select a Feed view for your package badge. If you're using release views, select the view that contains the
packages you want to share; otherwise, just use No view .
3. You'll see a preview of your badge. You can copy the Markdown version of your badge that includes alt text,
or a direct image link.
Add the markdown or direct image link to your README or any other place you want to share your package!
Delete and recover packages
2017
Azure Artifacts keeps all of your artifacts safe for as long as you need them, whether you published them directly
or saved them from upstream sources. But, as older artifacts fall out of use, you may want to clean them up or let
Azure Artifacts remove them automatically. In this article, you’ll learn how to:
1. Delete packages from Azure Artifacts feeds.
2. Set up retention policies to automatically delete older, unwanted packages from feeds.
3. Recover recently deleted packages from the recycle bin.
NOTE
To delete, recover packages and set up retention policies, you need to be an Owner of that particular feed.
Delete packages from Azure Artifacts feeds

Maven
npm
NuGet
Python
Universal
Choose the artifact from the Packages page in the Build and Release page group and select the appropriate
option from the menu:
When you publish a particular version of a package to a feed, that version number is permanently reserved. You
cannot upload a newer revision package with that same version number, or delete it and upload a new package at
the same version.
Automatically delete old package versions with retention policies

Over time, the number of versions for each package being hosted in your feed can grow quickly. You can set up
retention policies to automatically delete old packages and save storage space.
maximum number of versions : allow you to chose how many versions of a package you want to keep.
days to keep recently downloaded packages . Packages will be deleted only if they have not been
downloaded for the number of days set in here.
If you'd like to retain a package indefinitely, you can promote it to a view. Versions that got promoted to views are
exempt from retention policies and will not be deleted.
NOTE
Package demotion is not currently supported. If you want this feature to be added to future releases, please feel free to
Suggest a feature on our Azure DevOps Developer Community. See Get started with feed views for more information.
To configure retention policies:

1. Navigate to Azure Artifacts.
2. Select the gear icon in your feed and select Feed settings .
3. From the Feed details tab, in the Retention policies setting, enter the maximum number of versions per
package to retain, and the number of days to keep recently downloaded packages.
4. Select Save .
1. Select Build and Release , then Packages to navigate to your feed and select the gear icon.
2. From the Retention tab, enter the maximum number of versions per package to retain.
3. Select Save .
NOTE
When you enable retention policies, a version of a package will be deleted when both of the following criteria are met:
1. The number of published versions of that package reaches the maximum number of versions limit, AND
2. A version of that package has not been downloaded within the number of days to keep recently downloaded
packages .
Recover a deleted package from the recycle bin

Deleted packages will remain in the recycle bin for 30 days after which it will be permanently deleted. You must be
assigned an owner role in order for you to recover deleted packages.
1. Select Azure Artifacts.
2. Select "Recycle Bin".
3. Select the appropriate package then select the package version.
4. Select Restore to feed .
1. Select Build and Release , then Packages to navigate to your feed and select Recycle bin .
2. Select the appropriate package then select the package version.
3. Select Restore to feed .

Receive notifications when a new package version is
published
When you follow a package, you’ll be notified every time a new version of that package is published. Notifications
are sent to your preferred email address, which you can change from your organization preferences.
Steps
1. From the feed page, select the package you want to follow
2. Click the Follow button
Follow a package with views

If you’re using release views, you can get notifications when new version of a package is promoted to a view. This
can reduce the notification spam if a lot of packages are being published, but only a few are being promoted to a
view.
1. Go to the feed page
2. Filter to a view (e.g. @release)
3. Go to the package you want to follow
4. Click the Follow button
Follow a package from the notification settings page

In addition to following a package from the Feeds page, you can manage your personal notifications and set up a
personal notification for a package or set of packages from the Notification Settings page.
Get started with NuGet packages in Azure DevOps
Services and TFS
Before you start

For this quickstart, you must have NuGet installed and set up. To learn more about NuGet installation and set up,
see the official documentation.
This quickstart assumes you've already set up Azure Artifacts. You can check out how to license the extension in
the License Azure Artifacts guide.
Azure Artifacts is an extension that comes pre-installed on TFS 2017 or newer, if it was removed from your
organization, you can install it from the Marketplace page for Azure Artifacts.
Create a feed
Already have a feed? Skip to the next step.
There are two types of feeds: project scoped and organization scoped feeds. All public feeds are project-scoped
and they inherit the visibility settings of the hosting project.

NOTE
4. Select Create .
Azure Artifacts is installed by default for TFS 2017 customers. You must upgrade to TFS 2017 in order to use
Azure Artifacts. If this is the first time using your feed, you might be asked to assign a license
3. Give your feed a Name , a Description , and set up who can read , who can contribute and if you want
to Include external packages .
NOTE
Publish a package
Publish NuGet packages to a feed in Azure Artifacts to share them with your team and your organization.
First, get the tools and your feed URL:
1. Go to your feed (or create a feed if you haven't).
2. Select Connect to feed :
3. Select NuGet.exe under the NuGet header.

4. If you installed NuGet, and you have at least one edition of Visual Studio on your machine, you can move
to the next step. Otherwise:
a. Select Get the tools in the upper-right corner.
b. Download the latest NuGet version if you haven't yet.
c. Download and install the credential provider (if you don't have any Visual Studio edition).
5. Copy the xml code snippet in the Project setup section and add/create a nuget.config file for your
project. Place your file in the same folder as your . csproj or .sln file.
6. To publish your package to your feed, run the command in the Publish packages section in an elevated
PowerShell window. Don't forget to specify your local package path (for example:
..\HelloWorld\NuGetPackage\HelloWorld1.0.0.nupkg).
NOTE
The NuGet push command requires an API key. You can use any non-empty string for this variable. In our example, we
used the string key .
For more information on using credential providers with NuGet, see Creating a NuGet credential provider.
For more information on using personal access tokens, see Authenticate access with personal access tokens.
Publish a NuGet package by using the NuGet CLI

To publish your package by using the NuGet CLI, you need the following variables:
SourceName : The name of your feed created in step 1 of this article.
SourceURL : The feed URL (step 6). You can find it in the Project setup section, under value . In the Azure
DevOps portal, go to Ar tifact > Your feed name > Connect to feed > Project setup .
UserName and PAT : Your username and personal access token. For help with setting up your credentials, see
Authenticate access with personal access tokens.
3. Follow steps 1 and 2 to get the tools, add the feed to your local NuGet configuration, and push the
package.
NOTE
You can use the symbols of your NuGet packages to debug your application. You can publish your symbols to a file share
using the index sources and publish symbols task as well as in your build pipeline that produces the NuGet packages. See
Symbol files overview and How to publish your symbols for debugging for more information. Publishing your symbols to
Azure Artifact feeds from the command line is not currently supported.
Install and publish a sample NuGet package

If you don't have a package but want to try publishing, you can install a NuGet sample package from the public
NuGet gallery.
1. Install the sample NuGet package:
nuget install HelloWorld -ExcludeVersion
2. Publish the sample NuGet package to your feed.

Run these two commands in an elevated command prompt to add the source to your nuget.config file and
push your package to your feed. Replace the placeholders with the respective values.
nuget sources add -Name <SourceName> -Source <SourceURL> -username <UserName> -password <Pat>
nuget push -Source <SourceName> -ApiKey az <PackagePath exp:(.\Get-Hello.1.0.0.nupkg)>
Create and publish your own NuGet package

1. Create your own NuGet package by following the steps in Create NuGet packages.
2. Publish your package to your feed.
Consume your package in Visual Studio

To consume NuGet packages from a feed, add the feed's NuGet endpoint as a package source in Visual Studio.
NOTE
Azure Artifacts feeds work seamlessly with the NuGet Package Manager for Visual Studio 2015 extension as of Visual Studio
2015 Update 1. If you haven't installed Update 1 or later, you can update to the latest version of the NuGet Package
Manager extension directly. Using Visual Studio for Mac? See this guidance.
Get your feed's NuGet package source information

3. Select the Visual Studio tab under the NuGet header

4. Follow the instructions under Machine setup
3. Copy the NuGet package source URL:
Windows: Add the feed to your NuGet configuration

1. On the Tools menu, select Options .
2. Expand NuGet Package Manager and select Package Sources .
3. Select the green plus in the upper-right corner.
4. At the bottom of the dialog box, enter the feed's name and the URL that you got in the last step.
5. Select Update .
6. If you enabled the nuget.org upstream source, clear the check box for the nuget.org package source.
7. Select OK .
8. Go to the steps for consuming packages.
macOS: Add the feed to your NuGet configuration
1. Get a personal access token (PAT) and make a note of it.
2. Open the Preferences dialog box from the Visual Studio menu on the menu bar.
3. Select NuGet > Sources .
4. Select Add . Then enter your feed's name, the URL, any username, and your PAT as the password.
5. Select OK .
7. Select OK again.
Consume packages
You can now discover and use packages in this feed. To add a package reference to a project:
1. Find your project in Solution Explorer.
2. Right-click References .
3. Select Manage NuGet Packages .
4. In the Package source drop-down list, select your feed.
5. Look for your package in the list.
If you're using upstream sources, package versions in the upstream source that haven't yet been saved into your
feed (by using them at least once) won't appear in the NuGet Package Manager search. To install these packages:
1. On the upstream source (for example, nuget.org), copy the Install-Package command.
2. In Visual Studio, open the Package Manager Console from Tools > NuGet Package Manager .
3. Paste the Install-Package command into the Package Manager Console and run it.
Use symbols to debug

Symbol servers enable debuggers to automatically retrieve the correct symbol files for packages without knowing
product names, build numbers, or package names. If symbols have been published for your packages, connect
Visual Studio to the symbol server in Azure Artifacts to use symbols as you debug your packages.
Using Visual Studio 2013 or earlier

You'll need to get a personal access token. When you're prompted for a username and password, use any
username and your PAT as the password.
Automate the process with continuous integration

You can use continuous integration systems like Team Build to automate the packing and publishing of your
packages. To get started with continuous integration, see the NuGet in Team Build guidance.
What's next?
For more advanced topics, check out the content summary.
Publish to NuGet feeds (YAML/Classic)
Azure Pipelines | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 | TFS 2017
NOTE
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions,
runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called
phases.
You can publish NuGet packages from your build to NuGet feeds using the Pipeline tasks as well as the Classic
user interface. You can publish these packages to:
Azure Artifacts or the TFS Package Management service.
Other NuGet services such as NuGet.org.
Your internal NuGet repository.
Create a NuGet package

There are various ways to create NuGet packages during a build. If you're already using MSBuild or some other
task to create your packages, skip this section and publish your packages. Otherwise, add a NuGet task:
YAML
Classic
To create a package, add the following snippet to your azure-pipelines.yml file.
- task: NuGetCommand@2
inputs:
command: pack
packagesToPack: '**/*.csproj'
The NuGet task supports a number of options. The following list describes some of the key ones. The task
documentation describes the rest.
packagesToPack : The path to the files that describe the package you want to create. If you don't have these,
see the NuGet documentation to get started.
configuration : The default is $(BuildConfiguration) unless you want to always build either Debug or
Release packages, or unless you have a custom build configuration.
packDestination : The default is $(Build.ArtifactStagingDirectory) . If you set this, make a note of the location
so you can use it in the publish task.
YAML is not supported in TFS.
Package versioning
In NuGet, a particular package is identified by its name and version number. A recommended approach to
versioning packages is to use Semantic Versioning. Semantic version numbers have three numeric components,
Major.Minor.Patch .
When you fix a bug, you increment the patch ( 1.0.0 to 1.0.1 ). When you release a new backward-compatible
feature, you increment the minor version and reset the patch version to 0 ( 1.4.17 to 1.5.0 ). When you make a
backward-incompatible change, you increment the major version and reset the minor and patch versions to 0 (
2.6.5 to 3.0.0 ).
In addition to Major.Minor.Patch , Semantic Versioning provides for a prerelease label. Prerelease labels are a
hyphen ( - ) followed by whatever letters and numbers you want. Version 1.0.0-alpha , 1.0.0-beta , and
1.0.0-foo12345 are all prerelease versions of 1.0.0 . Even better, Semantic Versioning specifies that when you
sort by version number, those prerelease versions fit exactly where you'd expect: 0.99.999 < 1.0.0-alpha <
1.0.0 < 1.0.1-beta .
When you create a package in continuous integration (CI), you can use Semantic Versioning with prerelease labels.
You can use the NuGet task for this purpose. It supports the following formats:
Use the same versioning scheme for your builds and packages, if that scheme has at least three parts
separated by periods. The following build pipeline formats are examples of versioning schemes that are
compatible with NuGet:
$(Major).$(Minor).$(rev:.r) , where Major and Minor are two variables defined in the build pipeline.
This format will automatically increment the build number and the package version with a new patch
number. It will keep the major and minor versions constant, until you change them manually in the build
pipeline.
$(Major).$(Minor).$(Patch).$(date:yyyyMMdd) , where Major , Minor , and Patch are variables defined in
the build pipeline. This format will create a new prerelease label for the build and package while keeping
the major, minor, and patch versions constant.
Use a version that's different from the build number. You can customize the major, minor, and patch
versions for your packages in the NuGet task, and let the task generate a unique prerelease label based on
date and time.
Use a script in your build pipeline to generate the version.
YAML
Classic
This example shows how to use the date and time as the prerelease label.
variables:
Major: '1'
Minor: '0'
Patch: '0'
steps:
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
For a list of other possible values for versioningScheme , see the NuGet task.
Although Semantic Versioning with prerelease labels is a good solution for packages produced in CI builds,
including a prerelease label is not ideal when you want to release a package to your users. The challenge is that
after packages are produced, they're immutable. They can't be updated or replaced.
When you're producing a package in a build, you can't know whether it will be the version that you aim to release
to your users or just a step along the way toward that release. Although none of the following solutions are ideal,
you can use one of these depending on your preference:
After you validate a package and decide to release it, produce another package without the prerelease label
and publish it. The drawback of this approach is that you have to validate the new package again, and it
might uncover new issues.
Publish only packages that you want to release. In this case, you won't use a prerelease label for every
build. Instead, you'll reuse the same package version for all packages. Because you do not publish packages
from every build, you do not cause a conflict.
NOTE
Please note that DotNetCore and DotNetStandard packages should be packaged with the DotNetCoreCLI@2 task to
avoid System.InvalidCastExceptions. See the .NET Core CLI task for more details.
task: DotNetCoreCLI@2
displayName: 'dotnet pack $(buildConfiguration)'
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'

In the previous section, you learned how to create a package with every build. When you're ready to share the
changes to your package with your users, you can publish it.
YAML
Classic
To publish to an Azure Artifacts feed, set the Project Collection Build Ser vice identity to be a Contributor on
the feed. To learn more about permissions to Package Management feeds, see Secure and share packages using
feed permissions. Add the following snippet to your azure-pipelines.yml file.
steps:
- task: NuGetAuthenticate@0
displayName: 'NuGet Authenticate'
displayName: 'NuGet push'
inputs:
command: push
publishVstsFeed: '<projectName>/<feed>'
allowPackageConflicts: true
NOTE
Artifact feeds that were created through the classic user interface are project scoped feeds. You must include the project
name in the publishVstsFeed parameter: publishVstsFeed: '<projectName>/<feed>' . See Project-scoped feeds vs.
Organization-scoped feeds to learn about the difference between the two types.
To publish to an external NuGet feed, you must first create a service connection to point to that feed. You can do
this by going to Project settings , selecting Ser vice connections , and then creating a New ser vice
connection . Select the NuGet option for the service connection. To connect to the feed, fill in the feed URL and
the API key or token.
To publish a package to a NuGet feed, add the following snippet to your azure-pipelines.yml file.
- task: NuGetAuthenticate@0
inputs:
nuGetServiceConnections: '<Name of the NuGet service connection>'
inputs:
command: push
nuGetFeedType: external
versioningScheme: byEnvVar
versionEnvVar: <VersionVariableName>
Publish symbols for your packages

When you push packages to a Package Management feed, you can also publish symbols.
FAQ
Where can I learn more about Azure Artifacts and the TFS Package Management service?
Package Management in Azure Artifacts and TFS
Publish a NuGet package from the command line
Azure DevOps Ser vices | Team Foundation Ser ver 2018 | Team Foundation Ser ver 2017
Publish NuGet packages to a feed in Azure Artifacts to share them with your team and your organization.
First, get the tools and your feed URL:
3. Select NuGet.exe under the NuGet header.

4. If you installed NuGet, and you have at least one edition of Visual Studio on your machine, you can move to
the next step. Otherwise:
a. Select Get the tools in the upper-right corner.
b. Download the latest NuGet version if you haven't yet.
c. Download and install the credential provider (if you don't have any Visual Studio edition).
5. Copy the xml code snippet in the Project setup section and add/create a nuget.config file for your
project. Place your file in the same folder as your . csproj or .sln file.
6. To publish your package to your feed, run the command in the Publish packages section in an elevated
PowerShell window. Don't forget to specify your local package path (for example:
..\HelloWorld\NuGetPackage\HelloWorld1.0.0.nupkg).
NOTE
The NuGet push command requires an API key. You can use any non-empty string for this variable. In our example, we
used the string key .
For more information on using credential providers with NuGet, see Creating a NuGet credential provider.
For more information on using personal access tokens, see Authenticate access with personal access tokens.
Publish a NuGet package by using the NuGet CLI

To publish your package by using the NuGet CLI, you need the following variables:
SourceName : The name of your feed created in step 1 of this article.
SourceURL : The feed URL (step 6). You can find it in the Project setup section, under value . In the Azure
DevOps portal, go to Ar tifact > Your feed name > Connect to feed > Project setup .
UserName and PAT : Your username and personal access token. For help with setting up your credentials, see
Authenticate access with personal access tokens.
3. Follow steps 1 and 2 to get the tools, add the feed to your local NuGet configuration, and push the package.
NOTE
You can use the symbols of your NuGet packages to debug your application. You can publish your symbols to a file share
using the index sources and publish symbols task as well as in your build pipeline that produces the NuGet packages. See
Symbol files overview and How to publish your symbols for debugging for more information. Publishing your symbols to
Azure Artifact feeds from the command line is not currently supported.
Install and publish a sample NuGet package

If you don't have a package but want to try publishing, you can install a NuGet sample package from the public
NuGet gallery.
1. Install the sample NuGet package:
nuget install HelloWorld -ExcludeVersion
2. Publish the sample NuGet package to your feed.

Create and publish your own NuGet package

1. Create your own NuGet package by following the steps in Create NuGet packages.
2. Publish your package to your feed.
Work with upstream sources

Upstream sources enable you to use a single feed to store and consume packages from both public (NuGet.org,
npmjs.com, Maven Central, and PyPI) and authenticated feeds (Azure Artifacts feeds).
See Understanding upstream sources to get familiar with the concepts. You can also check out the following articles
to learn how to:
Set up upstream sources for Azure DevOps.
Protect your open-source software packages with upstream sources.
Consume NuGet packages in Visual Studio

To consume NuGet packages from a feed, add the feed's NuGet endpoint as a package source in Visual Studio.
NOTE
Azure Artifacts feeds work seamlessly with the NuGet Package Manager for Visual Studio 2015 extension as of Visual Studio
2015 Update 1. If you haven't installed Update 1 or later, you can update to the latest version of the NuGet Package
Manager extension directly. Using Visual Studio for Mac? See this guidance.
Get your feed's NuGet package source information

3. Select the Visual Studio tab under the NuGet header

4. Follow the instructions under Machine setup

Windows: Add the feed to your NuGet configuration

1. On the Tools menu, select Options .
2. Expand NuGet Package Manager and select Package Sources .
3. Select the green plus in the upper-right corner.
4. At the bottom of the dialog box, enter the feed's name and the URL that you got in the last step.
5. Select Update .
7. Select OK .
8. Go to the steps for consuming packages.
macOS: Add the feed to your NuGet configuration
1. Get a personal access token (PAT) and make a note of it.
2. Open the Preferences dialog box from the Visual Studio menu on the menu bar.
3. Select NuGet > Sources .
4. Select Add . Then enter your feed's name, the URL, any username, and your PAT as the password.
5. Select OK .
7. Select OK again.
Consume packages
You can now discover and use packages in this feed. To add a package reference to a project:
1. Find your project in Solution Explorer.
2. Right-click References .
3. Select Manage NuGet Packages .
4. In the Package source drop-down list, select your feed.
5. Look for your package in the list.
If you're using upstream sources, package versions in the upstream source that haven't yet been saved into your
feed (by using them at least once) won't appear in the NuGet Package Manager search. To install these packages:
1. On the upstream source (for example, nuget.org), copy the Install-Package command.
2. In Visual Studio, open the Package Manager Console from Tools > NuGet Package Manager .
3. Paste the Install-Package command into the Package Manager Console and run it.
Use symbols to debug

Symbol servers enable debuggers to automatically retrieve the correct symbol files for packages without knowing
product names, build numbers, or package names. If symbols have been published for your packages, connect
Visual Studio to the symbol server in Azure Artifacts to use symbols as you debug your packages.
Using Visual Studio 2013 or earlier
You'll need to get a personal access token. When you're prompted for a username and password, use any
username and your PAT as the password.
Use NuGet with Azure DevOps Services feeds
NOTE
This page covers interactive scenarios. In Azure Pipelines, use the NuGet step to restore and publish packages.
NOTE
The Azure Artifacts service recommends NuGet 4.8.2 or later. However, Azure Artifacts also supports legacy NuGet 2.x
clients. For a complete list of the latest clients, see the NuGet distribution page.
Add a feed to NuGet 4.8.2 or later

NuGet 4.8.2 and later supports the Azure Artifacts Credential Provider, which automatically acquires feed
credentials when needed. For more information on using credential providers with NuGet, see Creating a NuGet
credential provider.
1. Navigate to your feed (or create a feed if you haven't).
3. Select NuGet.exe under the NuGet header

4. Select Get the tools in the top-right corner
5. Follow steps 1 and 2 to download the latest NuGet version and the credential provider.
6. Follow the instructions in the Project setup , Restore packages , and Publish packages sections to
publish.
NOTE
You can also paste the Project setup XML snippet in your default nuget.config file to use outside of a project.
3. Follow steps 1, 2, and 3 to get the tools, add the feed to your local NuGet configuration, and push the
package.
Then, run any NuGet command.
Add a feed to NuGet 2

NuGet 2 uses Personal Access Tokens to access feeds.
To use a 2.x client, first get the v3 feed URL:
Then, at the end of the URL, replace /v3/index.json with /v2 .

Generate a Personal Access Token (PAT) using the instructions Authenticate access with personal access tokens.
Scope your PAT to the organization(s) you want to access and to one of the following scopes: Packaging (read),
Packaging (read and write), or Packaging (read, write, and manage).
NOTE
We strongly recommend not checking your PAT into source control. Anyone with access to your PAT can gain access
to your Azure DevOps Services.
Run
nuget sources add -name {your feed name} -source {your feed URL} -username {anything} -password {your PAT}

NuGet 2 uses Personal Access Tokens to access feeds.
To use a 2.x client, first get the v3 feed URL:
Then, at the end of the URL, replace /v3/index.json with /v2 .

Generate a Personal Access Token (PAT) using the instructions Authenticate access with personal access tokens.
Scope your PAT to the organization(s) you want to access and to one of the following scopes: Packaging (read),
Packaging (read and write), or Packaging (read, write, and manage).
NOTE
We strongly recommend not checking your PAT into source control. Anyone with access to your PAT can gain access
to your Azure DevOps Services.
Run
nuget sources add -name {your feed name} -source {your feed URL} -username {anything} -password {your PAT}

Use dotnet with Azure Artifacts feeds
On developer machines
3. Select dotnet under the NuGet header

4. Select Get the tools in the top right corner
5. Follow steps 1 , 2 , and 3 to download and install the latest .NET Core SDK and credential provider.
6. Follow the instructions in the Project setup , Restore packages , and Publish packages sections to
publish.
NOTE
You can also paste the Project setup XML snippet in your default nuget.config file to use outside of a project.
On build machines and in non-interactive scenarios

In Azure Pipelines, use the .NET Core step's restore command, which automatically handles authentication to Azure
Artifacts feeds. Otherwise, use the Azure Artifacts Credential Provider and pass in credentials using the
VSS_NUGET_EXTERNAL_FEED_ENDPOINTS environment variable.
Use NuGet or dotnet with Team Foundation Server
feeds
TFS 2018 | TFS 2017

Authentication from command-line clients like nuget and dotnet is a little different for Team Foundation Server
users.
Domain users on domain-joined machines

You can use consume packages with Visual Studio, publish with nuget, and use nuget and dotnet. Ignore any
content about the Credential Provider or Personal Access Tokens—everything will work using your domain
credentials.
Non-domain users (e.g. service accounts, users on non-domain-joined

machines)
This workflow is not recommended , because it requires that you store your encr ypted domain password
on disk. Please consider the security implications before continuing.

Then, run the following command (replacing {values} where applicable):
nuget sources add -name {your feed name} -source {your feed URL} -username {your domain username} -password
{your domain password}
Use packages from nuget.org
NOTE
NuGet upstream sources are only available for Azure DevOps Ser vices and TFS 2018 Update 2 and newer .
The NuGet client natively supports multiple package sources, so you can use packages from both nuget.org and
private feeds (like your Azure Artifacts feed). However, there are some limitations (outlined on the upstream
sources concepts page) with that configuration, and we recommend instead managing package sources server-
side using a single feed and upstream sources.
The nuget.org upstream source allows you to merge the contents of nuget.org into your feed such that the nuget
client can install packages from both locations without making multiple search queries. Enabling upstream
sources also automatically enables saving of packages you use from the upstream source.
To learn more about the concept of upstream sources, please see the concepts page.
Enable the upstream on a new feed

1. Create a new feed. Ensure you leave the "Use packages from public sources through this feed" radio button
selected.
2. Update your NuGet configuration.
Enable the upstream on an existing feed

IMPORTANT
Enabling the nuget.org upstream source on a widely-used feed can result in unexpected packages being saved into that
feed. Learn more
1. Edit your feed. Select the gear icon in the top right of the page to open feed settings.
2. Select the Upstream sources pivot.
3. Select Add upstream source in the CommandBar.
4. Select Select a feed URL and select nuget.org ( https://api.nuget.org/v3/index.json ) . If you like,
customize the upstream name.
5. Select Add .
6. Update your NuGet configuration.
Adding upstreams to a popular feed
Once you enable the nuget.org upstream source, any Owner or Contributor that runs a package request against
your feed can save packages from nuget.org into your feed. If you've distributed your feed URL to a large set of
consumers, this means that users outside your team could save packages you weren't expecting into your feed.
If you're concerned about this, consider creating a new feed then adding nuget.org and your current feed as
upstream sources to that feed.
Update your NuGet configuration
To use your feed and upstream source, follow the instructions to consume NuGet packages. If you've previously
set up this feed, still take a quick pass through those instructions and ensure you've disabled NuGet.org as a
source. This ensures that all package requests are sent to your Azure DevOps Services feed, which is required to
take advantage of the guaranteed save functionality of the nuget.org upstream source.
Filter to saved packages

You can see the packages you have saved in your feed by selecting the appropriate Source filter.
Set up a multi-developer NuGet environment

Using a package management system helps increase your team's velocity and decreases the amount of code
duplication across your organization. Multiple developers on a team need to coordinate where and how they
access packages. For example, developers will need a compatible NuGet client and credentials to authenticate to
any Azure DevOps Services hosted feeds before they can restore or push packages.
Team leaders or architects can make it very simple for developers to get everything they need without having to do
multiple downloads and find passwords and authentication tokens on team shares. We've developed a set of tools
and conventions for integrating Azure DevOps Services NuGet into your workflow. The tools are shipped as a
NuGet package called Microsoft.VisualStudio.Services.NuGet.Bootstrap , available on the public NuGet Gallery. We
also have an example repository which demonstrates these tools.
The bootstrapper package

The bootstrapper package takes care of several things for you:
Ensures that each developer has a compatible version of nuget.exe and the Azure DevOps Services
authentication extension in their environment
Separates feed configuration from credential management so you don't have to share passwords among
developers
Allows build and continuous integration systems to seamlessly use the same configuration as individual
developers
The bootstrapping tools work regardless of your version control system. Both Git and TFVC are supported.
You aren't required to use this bootstrapping package in order to use Azure DevOps Services authenticated feeds.
It's intended to help you get going without having to write a lot of code or invest in an extensive engineering
system. Customers with unique needs can copy the package and example repo, and modify them to fit in their
engineering system.
One -time setup
Perform the following steps one time in a repo containing your app's code. Anyone with the authority to make
solution-wide changes can follow these steps.
Open a PowerShell prompt and cd to the root directory of your app's code.
Get a copy of nuget.exe to use temporarily. The PowerShell command
Invoke-WebRequest https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile nuget.exe makes this
easy.
In the PowerShell window, run the command
.\nuget.exe install -OutputDirectory packages Microsoft.VisualStudio.Services.NuGet.Bootstrap to fetch the
bootstrapping tools.
Run .\packages\Microsoft.VisualStudio.Services.NuGet.Bootstrap.*\tools\Bootstrap.ps1 to initialize your
environment.
This will create a nuget.config in the root of your repo, where you can specify the feeds you want NuGet
to use.
It will also create an init script which developers and build agents run each time they want to work
with this repo. init ensures you always have the latest Azure DevOps Services NuGet tools and also
sets up authentication to Azure DevOps Services-hosted feeds.
Delete the copy of nuget.exe you downloaded earlier: rm .\nuget.exe
Going forward, this repo will rely on a copy of nuget.exe installed by the bootstrapping tools.
Update your .gitignore/.tfignore file to exclude .tools/ and packages/ .
Update nuget.config to list the feeds used by your app.
Check in the changes to your repo.
NOTE
By default, the bootstrapper disables the public NuGet Gallery as a package source. Many customers use private feeds as a
way to avoid dependencies on unknown or untrusted packages. If you depend on restoring packages from the public NuGet
Gallery, edit nuget.config and uncomment the line pointing to http://nuget.org (see the section on conventions for more
about nuget.config ).
Developer experience when using the bootstrapper package

The first time a developer enlists in a repo, they must run init in the root of the repo. This will ensure that NuGet
can connect to authenticated feeds with the developer's credentials. For more about init , see the section on
conventions.
At least once a month and whenever their password changes, the developer should refresh their environment by
running init again. If your developers already run a script when they work on code (for example, to update tools
or set environment variables), that script can call init each time it runs.
Conventions
The bootstrapper package places init.cmd , init.ps1 , and nuget.config in the root of your repo. init is the
entry point for tools which live under scripts\ and .tools\ . It's placed in the root for developer convenience.
Placing nuget.config in the root of the repo is a common NuGet convention.
Developer credentials are not placed in the repo's nuget.config . When init runs, it places credentials in the
user's NuGet config under %APPDATA% . When restoring or pushing packages, NuGet merges the sources list from
the repo and credentials from the machine-wide config.
Get started with npm packages in Azure Artifacts

This quickstart will show you how to create your Azure Artifact feed, set up your .npmrc files to store your feed
URLs and credentials, build your project and publish your npm package to your feed.
License the Azure Artifacts extension

Install Azure Artifacts in TFS
Azure Artifacts is installed by default for TFS 2017 customers. To use Azure Artifacts, you must upgrade to TFS
2017.
NOTE
If the Azure Artifacts extension has been removed, you can install it from the Marketplace page for Azure Artifacts.
Assign Azure Artifacts in Azure DevOps Services

Each organization gets five free licenses. If you need more than five licenses, go to the Marketplace page for Azure
Artifacts and select Get . Select Buy and purchase the additional licenses that you need.
Assign your licenses by following these instructions:
1. Go to your organization and select Admin settings on the lower left of the UX.
2. Select Users .
3. Select the user or users you want to assign the Azure Artifacts extension to, and select Manage extensions .
4. If you're selecting multiple users, select Assign extensions and choose the Azure Artifacts extension. If you're
selecting only one user, select the Azure Artifacts box under Extensions and select Save changes .
If you have a Visual Studio Enterprise license, you already have access to Azure Artifacts and don't need to be
assigned a license. Just ensure that you've been assigned the "Visual Studio Enterprise" access level.
1. Go to your account, go to the Users page, and select Package Management .
2. Select Assign , enter the users you want to assign licenses to, and then select Ok .
If you have a Visual Studio Enterprise license, you already have access to Package Management and don't need to
be assigned a license. Just ensure that you've been assigned the "Visual Studio Enterprise" access level.
Assign licenses in TFS
Each organization gets five free licenses. If you need more than five licenses, go to the Marketplace page for Azure
Artifacts and select Get . Select Buy and purchase the additional licenses that you need.
If you aren't sure, you can select Star t 30-day free trial . Every user in your organization is then granted access
to Azure Artifacts for 30 days. After the 30-day trial period, your organization reverts back to five entitled users,
and you must assign licenses to individual users. If you need additional licenses at this point, you can purchase
them from this same dialog box in the Marketplace.
NOTE
If you selected Star t 30 day free trial and are still in the trial period, every user is granted access. Licenses don't need to
be assigned until the trial period ends.
1. From any collection in TFS, hover over the settings menu and select the Users page. Then select Package
Management .
2. Select Assign , enter the users you want to assign licenses, and then select Ok .
Users with Visual Studio Enterprise subscriptions get Azure Artifacts for free. Make sure that your
Visual Studio Enterprise subscribers have the VS Enterprise access level. See Change access levels for
more information on how to set up permissions and change access levels.
Users who are using an instance of TFS that's disconnected from the internet (and thus can't
purchase licenses from the Marketplace) can still assign licenses purchased through an enterprise
agreement.
Create a feed
A feed is a container that allows users to group packages and control who can access them by modifying the feed
permissions.
Feeds are not package type dependent. Azure Artifacts currently supports the storage of all the following package
types in a single feed:
NuGet
npm
Maven
Python
Universal
On your first visit to Azure Ar tifacts , you're welcomed with an image that prompts you to create a new feed.
Select the Create feed button.
In the dialog box:
Name : Give the feed a name.
Visibility : Choose who can read and contribute (or update) packages in your feed. An organization-visible feed
is created with permissions that allow all users in the organization to see and use your feed (recommended). A
private feed is created with permissions such that only you have access.
Upstream sources : Selecting Use packages from public sources through this feed will add both the
public npm registry.npmjs.org and NuGet packages.nuget.org packages as upstreams to your feed. When
upstreams are enabled, your client (that is, npm and NuGet) can fetch packages from the public registry
through your private feed, and your private feed will cache those packages for you. If you select Use packages
published to this feed , your feed is created without connectivity to public registries. You can connect them
later if you want.
When you're done, select Create .
You can change these settings later by editing the feed.
Set up your .npmrc files

All Azure Artifacts feeds require authentication. You'll need to store credentials for the feed before you can install
or publish packages. npm uses .npmrc configuration files to store feed URLs and credentials.
Find your .npmrc files
We recommend that you use two .npmrc files:
1. One .npmrc should live at the root of your git repo adjacent to your project's package.json .
a. From your Ar tifacts page, click Connect to Feed
b. Select npm .
c. Select Get the tools in the upper-right corner
d. Follow steps 1 and 2 to download Node.js, npm, and the artifacts credential provider.
e. Select Windows if you are on a Windows Machine, or Other if you are on macOS or Linux.
f. Follow the instructions in the Project setup , Restore packages , and Publish packages sections
to publish.npm-azure
2. On your development machine, you will also have a .npmrc in $home for Linux or Mac systems or
$env.HOME for win systems. This .npmrc should contain credentials for all of the registries that you need
to connect to. The NPM client will look at your project's .npmrc , discover the registry, and fetch matching
credentials from $home/.npmrc or $env.HOME/.npmrc. Credential acquisition will be discussed in the next
section.
This enables you to share the project's .npmrc file with the whole team while keeping your credentials secure.
Set up authentication on your development machine
At this point, you should have a project-specific .npmrc file that contains only your feed's registry information that
you discovered from the Connect to feed dialog box. There should be no credentials in this file. The file is usually
adjacent to your project's package.json file.
IMPORTANT
There can be only a single "registry=" line in your .npmrc file. Multiple registries are possible with scopes and upstream
sources.
Windows
If you're developing on Windows, we recommend that you use vsts-npm-auth to fetch credentials and inject them
into your ~/.npmrc file on a periodic basis. The easiest way to set this up is to install vsts-npm-auth globally (that
is, npm install -g vsts-npm-auth ) and then add a run script in your project's package.json file.
"scripts": {
"refreshVSToken": "vsts-npm-auth -config .npmrc"
}
Linux or Mac
If you're developing on Linux or Mac, vsts-npm-auth is not supported. We recommend generating a token in the
following manner for your $HOME/.npmrc file.
The Connect to feed dialog box generates an appropriately formatted token that you can place into your .npmrc
file with a lifespan of 90 days.
TIP
If you want to create a token that lasts longer than 90 days, make sure you change the default expiration date.
Project setup:
1. From Azure Ar tifacts , select Connect to feed .
2. Select npm .
3. Select Other in the Project setup section.
4. Add a .npmrc to your project, in the same directory as your package.json
registry=https://pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/
always-auth=true
Set up credentials:
Set up credentials by following these four steps:
1. Step 1 :
Copy the code below to your user .npmrc file.
; begin auth token
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/:username=
[ANY_VALUE_BUT_NOT_AN_EMPTY_STRING]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/:_password=
[BASE64_ENCODED_PERSONAL_ACCESS_TOKEN]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/registry/:email=npm requires email to
be set but doesn't use the value
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:username=
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:_password=
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:email=npm requires email to be set
but doesn't use the value
; end auth token
2. Step 2 :
Generate a personal access token with Packaging read & write scopes.
3. Step 3 :
Base64 encode the personal access token from Step 2. Follow the steps below to safely encode your PAT:
a. From a command/shell prompt run the following:
node -e "require('readline')
.createInterface({input:process.stdin,output:process.stdout,historySize:0}) .question('PAT> ',p
=> { b64=Buffer.from(p.trim()).toString('base64');console.log(b64);process.exit(); })"
Other options to convert your personal access token to Base64:

Windows
Mac
[Convert]::ToBase64String([system.Text.Encoding]::UTF8.GetBytes("YOUR_PAT_GOES_HERE"))
b. Paste your personal access token value and press Enter/Return.

c. Copy the Base64 encoded value.
4. Step 4 :
Replace both [BASE64_ENCODED_PERSONAL_ACCESS_TOKEN] values in your user .npmrc file with your Base64
_encoded personal access token from Step 3. You should also replace yourOrganization and yourFeed , and
fill in your username, your PAT, and email.
1. From the Packages page, select Connect to feed .
2. Select npm .
3. Select Generate npm credentials . Copy the credentials to add them to your user .npmrc file manually:
NOTE
If you have npmjs.com configured as an upstream and the package name/version exists in the public registry, you'll be
blocked from publication. We don't support overriding packages that exist in the public registry. See packages from
npmjs.com for more details.
Build your project

At this point, your project should have a package.json file and an .npmrc file adjacent to each other. Run
npm install from the directory that contains both of these files. npm will discover your feed in the .npmrc file in
the current working directory. It will then fetch credentials from your home directory's .npmrc file that you
configured in Create a feed.
Publish an npm package

You can now publish the npm package:
1. Browse to the directory that contains your package's package.json file.
2. Run npm publish .
The npm publish command will authenticate to the feed using the .npmrc configuration files that you had to setup
in this previous step. See the npm CLI docs for more information.
If you have followed all of the steps up to this point, your npm package should be available now in your feed.
IMPORTANT
Ensure that your working folder has an .npmrc file with a registry= line, as described in the Connect to feed screen in
your feed. The build does not support using the publishConfig property to specify the registry to which you're
publishing. If you include the publishConfig property in your package.json file, the build will fail with potentially an
unrelated authentication error.
Next steps
Check out the Azure Artifacts landing page to learn about other topics.
Publish npm packages (YAML/Classic)
Azure Pipelines | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 | TFS 2017
NOTE
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs
are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.
You can publish npm packages produced by your build to:

Azure Artifacts or the TFS Package Management service.
Other registries such as https://registry.npmjs.org/ .
YAML
Classic
feed permissions.
Add the following snippet to your azure-pipelines.yml file.
- task: Npm@1
inputs:
command: publish
publishRegistry: useFeed
publishFeed: projectName/feedName
useFeed : this option allows the use of an Azure Artifacts feed in the same organization as the build.
feedName : the name of the feed you want to publish to.
projectName the name of your project.
NOTE
All new feeds that were created through the classic user interface are project scoped feeds. You must include the project
name in the publishFeed parameter: publishFeed: '<projectName>/<feedName>' . See Project-scoped feeds vs.
Organization-scoped feeds to learn about the difference between the two types.
To publish to an external npm registry, you must first create a service connection to point to that feed. You can do
this by going to Project settings , selecting Ser vices , and then creating a New ser vice connection . Select the
npm option for the service connection. Fill in the registry URL and the credentials to connect to the registry. See
Service connections to learn more about how to create, manage, secure, and use a service connection.
To publish a package to an npm registry, add the following snippet to your azure-pipelines.yml file.
- task: Npm@1
inputs:
command: publish
publishEndpoint: '<copy and paste the name of the service connection here>'
publishEndpoint : This argument is required when publishRegistry == UseExternalRegistry . Copy and paste
the name of the service connection you created earlier.
For a list of other options, see the npm task to install and publish your npm packages, or run an npm command.
NOTE
Ensure that your working folder has an .npmrc file with a registry= line, as described in the Connect to feed screen in
your feed.
The build does not support using the publishConfig property to specify the registry to which you're publishing. The
build will fail, potentially with unrelated authentication errors, if you include the publishConfig property in your
package.json configuration file.
FAQ
Where can I learn about the Azure Pipelines and TFS Package Management ser vice?
Check out the Azure Artifacts landing page for details about Artifacts in Azure Pipelines.
How to publish packages to my feed from the command line?
See Publish your package to an npm feed using the CLI for more information.
How to create a token that lasts longer than 90 days?
See Set up your client's npmrc for more information on how to set up authentication to Azure Artifacts
feeds.
Do you recommend using scopes or upstream sources?
We recommend using upstream sources because it gives you the most flexibility to use a combination of
scoped- and non-scoped packages in your feed, as well as scoped- and non-scoped packages from
npmjs.com.
See Use npm scopes and Use packages from npmjs.com for more details.
Publish an npm package from the command line

This article will show you how to connect your npm client to your feed in Azure Artifacts and share your packages
with your team and your organization.
If you don't have a feed yet, check out the Create a feed section in the npm quickstart to set up your own Azure
Artifacts feed.

To publish an npm package to your feed, follow these steps:
1. Set up the npm client with your feed.
2. Open a shell and navigate to the directory that contains your package's package.json file. If you don't have
a package.json file, run the following command:
npm init
See the npm CLI docs for a list of npm commands.

3. Push your package to your feed
npm publish
See the npm publish docs for more information on the publish command.
What's next?
Set up your client's npmrc

Azure Artifacts is an extension to Azure DevOps Services and Azure DevOps Server that makes it easy to discover,
install, and publish different types of packages. Check out Start using Azure Artifacts for more details.
All Azure Artifacts feeds require authentication, so you'll need to store credentials for the feed before you can
install or publish packages. npm uses .npmrc configuration files to store feed URLs and credentials.
Where are my .npmrc files?

Azure DevOps Services recommends using two .npmrc files:
1. One .npmrc should live at the root of your git repo adjacent to your project's package.json .
a. From your Packages page, click Connect to Feed
b. Select npm .
c. Select Get the tools in the top-right corner.
4. Follow steps 1 and 2 to download Node.js, npm, and the artifacts credential provider.
5. Follow the instructions under the Project setup section to set up your project. See the Restore
packages and Publish packages sections if you want to publish or restore your packages.
4. Follow the instructions in the Project setup and Restore packages sections.
4. Follow steps 1 and 2 to download Node.js, npm, and the artifacts credential provider.
5. Follow the instructions under the Project setup section to set up your project. See the Restore
packages and Publish packages sections if you want to publish or restore your packages.
2. On your development machine, you will also have a .npmrc in $home for Linux or Mac systems or
$env.HOME for win systems. This .npmrc should contain credentials for all of the registries that you need
to connect to. The NPM client will look at your project's .npmrc , discover the registry, and fetch matching
credentials from $home/.npmrc or $env.HOME/.npmrc. Credential acquisition will be discussed in the next
section.
This enables you to share project's .npmrc with the whole team while keeping your credentials secure.
Set up authentication on your dev box

You should have a project specific .npmrc containing only your feed's registry information that you discovered
from the "Connects to Feed" dialog. There should be no credentials in this file and the file itself is adjacent to your
project's package.json .
IMPORTANT
There can only be a single "registry=" line in your .npmrc. Multiple registries are possible with upstream sources, or by
using scopes (not recommended).
Windows
If you are developing on Windows, we recommend that you use vsts-npm-auth to fetch credentials and inject
them into your %USERPROFILE%\.npmrc on a periodic basis. The easiest way to set this up is to install
vsts-npm-auth globally (i.e. npm install -g vsts-npm-auth ) and then add a run script in your project's
package.json .
"scripts": {
"refreshVSToken" : "vsts-npm-auth -config .npmrc"
}
Linux or Mac
If you are developing on Linux or Mac, vsts-npm-auth is not supported and we recommend generating a token in
the following manner for your $HOME/.npmrc
TIP
Project setup:
2. Select npm .
always-auth=true
Set up credentials:
1. Step 1 :
; begin auth token
; end auth token
2. Step 2 :
3. Step 3 :

Windows
Mac

4. Step 4 :
2. Select npm .
vsts-npm-auth is not supported on on-premises TFS and Azure DevOps Server.
To work with packages from Azure Artifacts, set up your project to reference this feed. Create a new text file
.npmrc in the same directory as your package.json and copy the snippet below:
@[YOUR_SCOPE]/registry=FabrikamBasic/_packaging/FabrikamFeed/npm/registry/
To restore your packages, run the following command in your project directory:
npm install
Set up authentication in a build task

There are two options for setting up authentication in a build task:
Without a task runner
With a task runner (e.g. gulp)
Without a Task Runner
To set up npm authentication in a build task without a task runner, follow the directions below.
1. Select Azure Pipelines , it should automatically take you to the Builds page.
2. Create a new pipeline.
3. Choose your source Project , Repositor y , and Default branch and select Continue.
4. Start with an Empty job .
5. On the left side, select the plus sign ( + ) to add a task to Job 1 . On the right side, select the Package
category, select the npm task from the list, and then choose Add .
6. Select the npm install task, then browse to and select your Working folder with package.json :
7. Expand Custom registries and authentication , here you have a few options:
Registries in my .npmrc
NOTE
You can choose credentials to authenticate to services outside of your current organization/collection by
setting up service connections.
Registry I select here
When you choose this option, the task will create a temporary .npmrc with credentials for the
registry you've selected and it will override the project's .npmrc . This is useful when you want to
publish to a specific feed.
8. Select Save & queue , and then select Save .
TIP
If your NPM Install build task is failing with Error 403, then make sure you set your build service as a contributor. To do so,
go to Azure Artifacts -> Select your feed -> Settings -> Permissions -> set your build service role to contributor.
1. Select Build and Release , and then choose Builds .
category, select the npm task from the list, and then choose Add .
6. Select the npm install task, then browse to and select your Working folder with package.json :
7. Expand Custom registries and authentication , here you have a few options:
Registries in my .npmrc
NOTE
You can choose credentials to authenticate to services outside of your current organization/collection by
setting up service connections.
Registry I select here
When you choose this option, the task will create a temporary .npmrc with credentials for the
registry you've selected and it will override the project's .npmrc . This is useful when you want to
publish to a specific feed.
8. Select Save & queue , and then select Save .
With a Task Runner (e.g. make gulp work)
When using a task runner, you'll need to add the npm Authenticate build task at the beginning of your build
pipeline. This will inject credentials into your project's .npmrc and persist them for the lifespan of the build. This
allows subsequent build steps to use the credentials in the .npmrc .
1. Select Azure Pipelines , it should automatically take you to the Builds page.
category, select the npm Authenticate task from the list, and then choose Add .
6. Select the npm Authenticate task underneath Phase 1 :

7. Browse to and select your .npmrc file to authenticate :
NOTE
You can choose credentials to authenticate to services outside of your current organization/collection by setting up
service connections.
8. After setting up your npm Authenticate task, you can add other build task(s) for your task runner like
Gulp .
1. Select Build and Release , and then choose Builds .

category, select the npm Authenticate task from the list, and then choose Add .
6. Select the npm Authenticate task underneath Phase 1 :
7. Browse to and select your npmrc file to authenticate :

NOTE
You can choose credentials to authenticate to services outside of your current organization/collection by setting up
service connections.
8. After setting up your npm Authenticate task, you can add other build task(s) for your task runner like
Gulp .
Troubleshooting vsts-npm-auth
If you receive an error like:
Command Prompt:
'vsts-npm-auth' is not recognized as an internal or external command, operable program or batch file.
PowerShell:
vsts-npm-auth : The term 'vsts-npm-auth' is not recognized as the name of a cmdlet, function, script file,
or operable program.
then it's likely that the npm modules folder is not in your path.
To fix this issue, rerun Node.js setup and ensure the Add to PATH option and its child options are selected for
installation.
Alternatively, you can edit the PATH variable to add %APPDATA%\npm (Command Prompt) or $env:APPDATA\npm
(PowerShell).
Next steps
Publish npm packages to your feed
Use packages from npmjs.com

The npm client is designed to work with a single primary registry (what Azure Artifacts calls a feed). It also
supports secondary scoped registries. Scoped registries can only be used to install packages whose names begin
with the scope prefix, so their usage is more restrictive. If you want to use both private packages you've created
and public packages from npmjs.com, we recommend using upstream sources.
The npmjs.com upstream source allows you to merge the contents of npmjs.com into your feed such that the npm
client can install packages from both locations. Enabling upstream sources also automatically enables saving of
packages you use from the upstream source. This is the recommended way to use Azure Ar tifacts with
npm. Upstreams give you the most flexibility to use a combination of scoped- and non-scoped packages in your
feed, as well as scoped- and non-scoped packages from npmjs.com.
Enable npmjs.com as an upstream

To use npmjs.com as an upstream source, either create a new feed or edit an existing feed.
On a new feed
selected.
On an existing feed
4. Select Select a feed URL and select npmjs.com ( https://registr y.npmjs.org ) . If you like, customize the
upstream name.
5. Select Add .

NOTE
Legacy feeds do not guarantee that every package npm install ed via a feed with upstreams enabled will be saved. Check
if your feed is a legacy feed and consider upgrading it, if needed.
Scopes
If you prefer to use scopes, which limit your private packages to those with the @<scope> prefix e.g.
@fabrikam/core but enable you to consume public packages directly from npmjs.com, see Scopes.
Use npm scopes

Scopes are built into npm and are a way of grouping packages together. In Azure DevOps Services and in
npmjs.com, you can publish and use both scoped and unscoped packages.
A scope allows you to create a package with the same name as a package created by another user or Org without
conflict. They allow the user to separate public and private packages by prefixing their packages with a scope
@fabrikam and configuring the .npmrc file to only use an Azure Artifacts feed for that scope.
NOTE
In order to use scopes you must be using npm version 2 or greater. Run npm install npm@latest -g on the command
line to upgrade to the latest version.
Set up
Scoped packages allow you to group similar npm packages together. This provides us with several advantages
including:
We don't have to worry about name collisions.
No need to change the npm registry in order to install or publish your packages.
Each npm organization/user has their own scope, and only the owner or the scope members can publish
packages to their scope.
To use an Azure Artifacts feed with a scope, follow the instructions below, but append your scope to both lines in
the project .npmrc file.
TIP
Project setup:
2. Select npm .
always-auth=true
Set up credentials:
1. Step 1 :
; begin auth token

; end auth token
2. Step 2 :
3. Step 3 :

Windows
Mac

4. Step 4 :
2. Select npm .
Then, replace:
registry=<your feed URL> with @fabrikam:registry=<your feed URL>
NOTE
Make sure you add the scope and package names to your package.json file: { "name": "@fabrikam/package-name" } .
Upstream sources or scopes?

Scopes add an additional restriction when naming your packages: each package name must start with @<scope> . If
you're ok with this limitation, and don't intend to ever publish your private packages to npmjs.com, scopes are an
alternative to upstream sources.
If you do intend to publish private packages to npmjs.com, we recommend not using scopes unless you intend to
publish your packages to npmjs.com with the scope intact; if you remove the scope when transitioning the
package from Azure Artifacts to npmjs.com, you'll need to update any package.json references accordingly.
Use npm audit
The npm audit command assesses your package dependencies for security vulnerabilities. Performing security
audits helps protect your package's users by helping you find and fix known vulnerabilities in dependencies. Fixing
these vulnerabilities could prevent things like data loss, service outages, unauthorized access to sensitive
information, or other issues.
Currently, Azure DevOps Services does not support the npm audit command, if you run npm audit to analyze your
packages in Azure DevOps Services, you will get a failure with the message:
Unexpected end of JSON input while parsing near.. .
As a workaround, you can run npm audit with the --registry=https://registry.npmjs.org/ set. This will route the
npm audit command directly to npmjs .
WARNING
Running the npm audit command will send the name of any private packages in your package.json to npmjs.com. You
shouldn't do this if your private package names are confidential or proprietary.
Run 'npm audit' in your pipeline

Below you will find instructions on how to run npm audit in your pipeline with both YAML and the designer.
YAML
Classic
steps:
- task: Npm@1
displayName: 'npm custom'
inputs:
command: custom
verbose: false
customCommand: 'audit --registry=https://registry.npmjs.org/'
Run 'npm audit' on your developer machine

To run npm audit from your developer machine, add the --registry=https://registry.npmjs.org/ flag to your
command. The full command will look like:
npm audit --registry=https://registry.npmjs.org/

Get started with Maven feeds and Artifacts
Before you start

This quickstart assumes you've already set up Azure Artifacts. You can check out how to license the extension in the
License Azure Artifacts guide.
NOTE
Azure Artifacts is an extension that comes pre-installed on TFS 2017 or newer (Maven is only available in 2018 or newer), if it
was removed from your organization, you can install it from the Marketplace page for Azure Artifacts.
Prerequisites
1. Apache Maven installed. You can download it from the Apache Maven site.
2. Have Azure Artifacts installed in your organization.
Create a feed
Already have a feed? Skip to the next step.
There are two types of feeds: project scoped and organization scoped feeds. All public feeds are project-scoped and
they inherit the visibility settings of the hosting project.

NOTE
4. Select Create .
Azure Artifacts is installed by default for TFS 2017 customers. You must upgrade to TFS 2017 in order to use Azure
Artifacts. If this is the first time using your feed, you might be asked to assign a license
3. Give your feed a Name , a Description , and set up who can read , who can contribute and if you want
to Include external packages .
NOTE
To talk to Azure Artifact feeds, you'll need a token on your local machine that Maven can pick up and pass to Azure
DevOps Services.
1. From the Azure Ar tifacts page, select Connect to Feed .
2. From the Packages page, select Connect to Feed .
3. Open the Maven tab under the maven header.

Maven pulls credentials from your settings.xml file.
On Linux, the file path is usually "${user.home}/.m2/settings.xml" .
On macOS, the file path is usually "~/.m2/settings.xml" .
On Windows, the file path is usually "%USERPROFILE%/.m2/settings.xml" .
If the file doesn't exist, create one now.
TIP
To make sure you create and save your new XML file in the correct format, set File Explorer to show file name
extensions:
1. In File Explorer, select the View tab.
2. Under Show/hide , select the File name extensions check box to see your files extensions in File Explorer.
4. If you haven't installed Maven on your machine, you can select Get the tools to download and install it.
5. Follow the Project setup section including generating a personal access token.
You can find more information about the settings.xml file in the settings.xml reference.
Publish an artifact
Publish Maven artifacts to a feed in Azure Ar tifacts to share them with your team and organization.
To publish a Maven artifact, you'll need to have a Maven artifact to publish on your local machine. If you don't have
one, you can generate one by running the following command:
mvn -B archetype:generate -DarchetypeGroupId="org.apache.maven.archetypes" -DgroupId="MyGroup" -

DartifactId="myFirstApp"
1. Set up the Maven client with your feed.

2. Navigate to the directory containing your Maven artifact's pom.xml file. If you've just created an artifact,
the pom.xml file will be in the myFirstApp folder.
3. From the directory containing your pom.xml file, run the following commands to build and deploy your
Maven artifact:
Build your package :
mvn build
Publish your package :
mvn deploy
Your Maven artifact should appear in your feed now. See the Apache Maven Deploy Plugin to learn more about
Maven deployment.
TIP
If you want to publish a 3rd party assembly to a Maven feed, you can use the deploy:deploy-file Mojo. This mojo is used
primarily to publish artifacts that were not built by Maven and you can use it with or without a POM file.
mvn deploy:deploy-file -Dpackaging="jar" -DrepositoryId="MyFeedName" -Durl="MyFeedURL" -DgroupId="MyGroup" -

DartifactId="myFirstApp" -Dversion="jarFileVersion" -Dfile="jarFileLocalPath"
IMPORTANT
Install an artifact from your feed

Install Maven artifacts from your feed by using the Maven client.
The most common way to install a Maven artifact is as a dependency of another artifact.
1. Create a Maven artifact by using the following command:

DartifactId="mySecondApp"
2. In Azure Ar tifacts , browse to the artifact that you want to install and copy the contents of the
<dependency> element.
3. Paste the <dependency> element content inside the <dependencies> element of your pom.xml file.
4. Run mvn install from the directory that contains your pom.xml file.
See the Maven CLI docs for more installation options.


2. From the Connect to feed dialog box in TFS, copy the <repository> information. Paste it into your
pom.xml file twice (see the preceding sample file):
Between the <repositories> tags
Between the <distributionManagement> tags
3. From the Packages page, browse to the artifact that you want to install and copy the contents of the

Automate the process with continuous integration
You can use continuous integration systems such as Team Build to automate the installation and publishing of your
Maven artifacts. To get started with continuous integration, see the Maven in Team Build guidance.
What's next?
Set up Azure Pipelines and Maven
Azure Pipelines | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018
NOTE
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs
are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.
This guide covers the basics of using Azure Pipelines to work with Maven artifacts in Azure Artifacts feeds.
Set up your feed

1. Select Build and Release .
2. Select Packages .
3. With your feed selected, select Connect to feed .
4. Select Maven .
5. Click on "Generate Maven Credentials"

6. Create a local file named settings.xml from the following template and then paste the generated XML,
replacing the comment:
IMPORTANT
Do not commit this file into your repository.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>

</servers>
</settings>
7. Below the settings.xml snippet in the generated credentials dialog, there is a snippet to be added to the
<repositories> section of your project's pom.xml . Add that snippet. If you intend to use Maven to publish
to Artifacts, add the snippet to the <distributionManagement> section of the POM file as well. Commit and
push this change.
8. Upload settings.xml created in step 3 as a Secure File into the pipeline's library.
9. Add tasks to your pipeline to download the secure file and to copy it to the (~/.m2) directory. The latter can
be accomplished with the following PowerShell script, where settingsxml is the reference name of the
"Download secure file" task:
New-Item -Type Directory -Force "${HOME}/.m2"

Copy-Item -Force "$(settingsxml.secureFilePath)" "${HOME}/.m2/settings.xml"
1. Navigate to Ar tifacts .
2. With your feed selected, select Connect to feed .
3. Select Maven .
4. Set up your project by following these steps:

a. Add the repo to both your pom.xml's <repositories> and <distributionManagement> sections.
Replace the [ORGANIZATION_NAME] placeholder with your own organization.
<repository>
<id>[ORGANIZATION_NAME]</id>
<url>https://pkgs.dev.azure.com/[ORGANIZATION_NAME]/_packaging/[ORGANIZATION_NAME]/maven/v1</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
</snapshots>
</repository>
b. Add or edit the settings.xml file in ${user.home}/.m2. Replace the [ORGANIZATION_NAME] placeholder
with your own organization.
<server>
<id>[ORGANIZATION_NAME]</id>
<username>[ORGANIZATION_NAME]</username>
<password>[PERSONAL_ACCESS_TOKEN]</password>
</server>
c. Generate a Personal Access Token with Packaging read & write scopes and paste it into the
<password> tag.
IMPORTANT
In order to automatically authenticate Maven feeds from Azure Artifacts, you must have the mavenFeedAuthenticate
argument set to true in your Maven task. See Maven build task for more information.
Restore your package

Run this command in your project directory to restore your package.
mvn build
Publish your package

Run this command in your project directory to publish your package.
mvn deploy
Publish Maven artifacts from the command line

Publish Maven artifacts to a feed in Azure Ar tifacts to share them with your team and organization.
To publish a Maven artifact, you'll need to have a Maven artifact to publish on your local machine. If you don't have
one, you can generate one by running the following command:

DartifactId="myFirstApp"
1. Set up the Maven client with your feed.

2. Navigate to the directory containing your Maven artifact's pom.xml file. If you've just created an artifact, the
pom.xml file will be in the myFirstApp folder.
3. From the directory containing your pom.xml file, run the following commands to build and deploy your
Maven artifact:
Build your package :
mvn build
Publish your package :
mvn deploy
Your Maven artifact should appear in your feed now. See the Apache Maven Deploy Plugin to learn more about
Maven deployment.
TIP
If you want to publish a 3rd party assembly to a Maven feed, you can use the deploy:deploy-file Mojo. This mojo is used
primarily to publish artifacts that were not built by Maven and you can use it with or without a POM file.
mvn deploy:deploy-file -Dpackaging="jar" -DrepositoryId="MyFeedName" -Durl="MyFeedURL" -DgroupId="MyGroup" -

DartifactId="myFirstApp" -Dversion="jarFileVersion" -Dfile="jarFileLocalPath"
IMPORTANT
Set up the Maven client in Azure DevOps Services
and TFS

To talk to Azure Artifact feeds, you'll need a token on your local machine that Maven can pick up and pass to Azure
DevOps Services.
1. From the Azure Ar tifacts page, select Connect to Feed .
2. From the Packages page, select Connect to Feed .
3. Open the Maven tab under the maven header.

Maven pulls credentials from your settings.xml file.
On Linux, the file path is usually "${user.home}/.m2/settings.xml" .
On macOS, the file path is usually "~/.m2/settings.xml" .
On Windows, the file path is usually "%USERPROFILE%/.m2/settings.xml" .
If the file doesn't exist, create one now.
TIP
To make sure you create and save your new XML file in the correct format, set File Explorer to show file name
extensions:
1. In File Explorer, select the View tab.
2. Under Show/hide , select the File name extensions check box to see your files extensions in File Explorer.
4. If you haven't installed Maven on your machine, you can select Get the tools to download and install it.
5. Follow the Project setup section including generating a personal access token.
You can find more information about the settings.xml file in the settings.xml reference.
Install Maven artifacts using Azure DevOps Services
and TFS

Install Maven artifacts from your feed by using the Maven client.
The most common way to install a Maven artifact is as a dependency of another artifact.

2. In Azure Ar tifacts , browse to the artifact that you want to install and copy the contents of the

2. From the Connect to feed dialog box in TFS, copy the <repository> information. Paste it into your
pom.xml file twice (see the preceding sample file):
Between the <repositories> tags
Between the <distributionManagement> tags
3. From the Packages page, browse to the artifact that you want to install and copy the contents of the
Sample pom.xml :
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>MyGroup</groupId>
<artifactId>myFirstApp</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>myFirstApp</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<repositories>

<repository>
<id>dev.azure.com-mseng-zcalvinmaven</id>
<url>https://dev.azure.com/mseng/_packaging/zCalvinMaven2/maven/v1</url>
<releases>
</releases>
<snapshots>
</snapshots>
</repository>
</repositories>
<distributionManagement>

<repository>
<id>dev.azure.com-mseng-zcalvinmaven</id>
<url>https://dev.azure.com/mseng/_packaging/zCalvinMaven2/maven/v1</url>
<releases>
</releases>
<snapshots>
</snapshots>
</repository>
</distributionManagement>
</project>
IMPORTANT
The <id> tags in the settings.xml and the pom.xml must match.
Use packages from Maven Central
Azure DevOps Ser vices | Azure DevOps Ser ver 2019 | Azure DevOps Ser ver 2020
If you want to use both private packages you've created and public packages from Maven Central, we recommend
using upstream sources.
The Maven Central upstream source allows you to merge the contents of Maven Central into your feed such that
the Maven client can install packages from both locations. Enabling upstream sources also automatically enables
saving of packages you use from the upstream source. This is the recommended way to use Azure Ar tifacts
with Maven.
IMPORTANT
Enable Maven Central as an upstream

To use Maven Central as an upstream source, either create a new feed or edit an existing feed.
On a new feed
selected.
On an existing feed
4. Select Select a feed URL and select Maven Central ( https://repo.maven.apache.org/maven2/ ) . If you
like, customize the upstream name.
5. Select Add .

Get started with Python packages in Azure Artifacts
Azure DevOps Ser vices | Azure DevOps Ser ver 2019 | Azure DevOps Ser ver 2020
This quickstart guides you through using Azure Artifacts to publish and consume Python packages by creating and
connecting to a feed.
Create a feed
1. Select Ar tifacts (in the left navigation of your Azure DevOps project).
2. On the Ar tifacts page, select Create Feed .
3. In the Create new feed dialog box:
In the Name field, give the feed a name.
PyPI is the default repository name for twine , which is a tool for publishing Python packages. It's
best not to name your feed PyPI because if you don't use -r to specify a repository name when
pushing, you might accidentally push to the wrong repository.
Under Visibility , select who can read, contribute, or update packages in your feed. The
recommended **People in your organization setting allow all members in your organization to view
and use your feed.
Under Packages from public sources , select Use packages from public sources through this
feed to add the public npm , NuGet , and PyPI registries as upstream sources to your feed.
NOTE
After enabling these upstream sources your client will be able to fetch packages from the public registry
through your private feed. Your private feed then will cache those packages for you. If you select Only use
packages published to this feed , your feed won't be connected to the public registries. You can still
connect to those public registries later if you chose to.
4. Select Create .
To edit your feed settings, select the gear icon at the upper right corner of the feed page.
Connect to your feed

There are two primary ways to connect to a feed to push or pull Python packages:
Install and use the Python Credential Provider (artifacts-keyring) (preview), which sets up authentication for
you.
Manually set up credentials for pip.ini / pip.conf for pushes, or .pypirc for pulls, through a personal access
token (PAT).
Option 1: Use Python Credential Provider (preview) to automate authentication
The Python Credential Provider is an artifacts-keyring package in public preview that you can install from the
Python Package Index (PyPI). The Python Credential Provider lets the pip and twine commands authenticate by
sending you through an authentication flow in your web browser.
The Python Credential Provider is a manual interaction. If you want to set up authentication in an Azure Pipelines
pipeline, use the Pip Authenticate task to install packages, or the Twine Upload Authenticate task to push packages.
IMPORTANT
You must have pip version 19.2 and twine version 1.13.0 or higher installed to use the Python Credential Provider.
1. From your command line, install the artifacts-keyring package:
pip install artifacts-keyring --pre
2. Install or upload packages to your feed.

For pip installs, run the following command:
pip install <package-name> --index-url https://pkgs.dev.azure.com/<your-organization-

name>/_packaging/<your-feed-name>/pypi/simple
For twine uploads, run the following command:
twine upload --repository-url https://pkgs.dev.azure.com/<your-organization-name>/_packaging/<your-feed-

name>/pypi/upload
3. Follow the authentication flow in your browser.

Option 2: Manually configure authentication
1. From your feed in Azure Ar tifacts , select Connect to feed .
2. Choose either pip or twine under the Python header.
NOTE
You can use the Get the tools button to get pip , twine and the ar tifacts keyring .
3. Follow the instructions under Project setup to set up your project.

4. To publish your package, follow the steps in the Publish packages section.
For more information, check out the following resources to:
Publish a package to your feed by using Python’s twine command.
How to consume and download packages by using pip.
Next steps
To consume or publish Python packages as part of your continuous integration/continuous delivery (CI/CD)
pipeline, see Publish Python packages in Azure Pipelines.
To learn more about how to create, configure, and use Python packages as part of your project or pipeline, see
Build Python apps.
If you’d like to learn more about how Python packages work, see The Architecture of Open Source Applications:
Python Packaging, an excerpt from the book Architecture of Open Source Applications.
Publish Python packages in Azure Pipelines
You can publish Python packages produced by your build to:

Azure Artifacts
Other repositories such as https://pypi.org/
To publish Python packages produced by your build, you'll use twine, a widely used tool for publishing Python
packages. This guide covers how to do the following in your pipeline:
1. Install twine on your build agent
2. Authenticate twine with your Azure Artifacts feeds
3. Use a custom task that invokes twine to publish your Python packages
Install twine
First, you'll need to run pip install twine to ensure the build agent has twine installed.
YAML
Classic
- script: 'pip install twine'
Check out the script YAML task reference for the schema for this command.
Authenticate Azure Artifacts with twine

To use twine to publish Python packages, you first need to set up authentication. The Python Twine Authenticate
task stores your authentication credentials in an environment variable ( PYPIRC_PATH ). twine will reference this
variable later.
YAML
Classic
To authenticate with twine , add the following snippet to your azure-pipelines.yml file.
The example below will enable you to authenticate to a list of Azure Artifacts feeds as well as a list of service
connections from external organizations. If you need to authenticate to a single feed, you must replace the
following arguments: artifactFeeds and externalFeeds with artifactFeed and externalFeed and specify your
feed name accordingly.
- task: TwineAuthenticate@0
inputs:
artifactFeeds: 'feed_name1, feed_name2'
externalFeeds: 'feed_name1, feed_name2'
ar tifactFeeds : a list of Azure Artifacts feeds within your organization.

externalFeeds : a list of service connections from external organizations including PyPI or feeds in other
organizations in Azure DevOps.
TIP
The authentication credentials written into the PYPIRC_PATH environment variable supersede those in your .ini and .conf
files.
If you add multiple Python Twine Authenticate tasks at different times in your pipeline steps, each additional build task
execution will extend (not override) the existing PYPIRC_PATH environment variable.
Use a custom twine task to publish

After you've set up authentication with the preceding snippet, you can use twine to publish your Python packages.
The following example uses a custom command-line task.
YAML
Classic
- script: 'twine upload -r {feedName/EndpointName} --config-file $(PYPIRC_PATH) {package path to publish}'
Check out the YAML schema reference for more details on the script keyword.
WARNING
We strongly recommend NOT checking any credentials or tokens into source control.
Publish and then download a Universal Package
Universal Packages store one or more files together in a single unit that has a name and version. You can publish
Universal Packages from the command line by using the Azure CLI.
This quickstart shows you how to publish your first Universal Package by using the CLI, and how to download it by
using the CLI. To see your package, you can go to your feed in Azure Artifacts.
Prerequisites
1. Download and install the latest build of the Azure CLI.
2. If you're using Linux, ensure you've installed the .NET Core Linux prerequisites.
3. Version 0.14.0 or greater of the Azure DevOps extension for the Azure CLI is required.
You can install the Azure DevOps extension using the following command:
az extension add --name azure-devops
To check the extension version that you currently have, run the following command:
az --version
You can upgrade to the latest Azure DevOps extension with the following command:
az extension update --name azure-devops
Prepare files for publishing

Create a new directory, and copy the files you want to publish as a package into that directory.
Create a feed
A feed is a container that host your packages. You can publish and consume your packages through a particular
feed.
If you don't already have an Azure Artifacts feed, create one now and note its name. If you already have a feed, just
note the name and Skip to the next step of this article to learn how to publish your universal packages.
1. Go to Ar tifacts :
2. Select Create feed :
3. In the dialog box:

Choose who can read and contribute (or update) packages in your feed.
Choose the upstream sources for your feed.
When you're done, select Create .
Most of the default settings work great for most feed users. Making your feed organization visible means
you can share a single source of packages across your entire team.
Enabling upstream sources to public sources makes it easy to use your favorite OSS packages as well as
gives you more protection against outages and corrupted or compromised packages.
You can still change these settings later from your feed settings.
With your feed selected, select the gear icon to access the Feed settings .
Log in to Azure DevOps

The following sections vary based on whether you've opted in to the new Azure DevOps Services URLs.
New URLs
Legacy URLs
After you've installed the CLI, open your shell of choice (for example, PowerShell or cmd) and browse to the
directory that you just created. Then, log in to Azure DevOps by using the following command. Replace the items in
square brackets ( [] ) with appropriate values.
az login
Next, set the organization that you just logged in to as the CLI's default. Again, replace the item in square brackets.
az devops configure --defaults organization=https://dev.azure.com/[your-organization] project=ContosoWebApp
Publish a Universal Package

Publish a package with az artifacts universal publish . The following example publishes a package named my-
first-package with version 1.0.0 to the FabrikamFiber feed in the fabrikam organization with a placeholder
description.
Update these values as desired, and use the feed name that you noted earlier. Package names must be lowercase
and can use only letters, numbers, and dashes ( - ). Package versions must be lowercase Semantic Versioning
(SemVer) 2.0.0 without build metadata ( + suffix).
New URLs
Legacy URLs
az artifacts universal publish --organization https://dev.azure.com/fabrikam --feed FabrikamFiber --name my-

first-package --version 1.0.0 --description "Your description" --path .
View the package in your feed

To see the package that you just published, go to the organization that you specified in the publish command,
select any project, and then select the Ar tifacts icon on the left side navigation.
Download a Universal Package

Now that you've published a package, you can download it to a different directory on your machine. To do that,
make a new directory and switch to it. Then run the command in the example to download your package.
You must use the Azure CLI to download the package. Azure DevOps doesn't support direct HTTP/HTTPS download
links or other ways to download the package.
The following example downloads a package with the same metadata as the publish example. Update these values
to match the values that you selected when you published your package.
New URLs
Legacy URLs
az artifacts universal download --organization https://dev.azure.com/fabrikam --feed FabrikamFiber --name my-

first-package --version 1.0.0 --path .
Filtered Universal Package downloads

For large Universal Packages, you might want to download a few files instead of the entire package. You can use
the --file-filter feature to download a subset of the Universal Package files.
The --file-filter command follows the .gitignore syntax. Make sure you have the latest Azure DevOps CLI
extension: az extension update -n azure-devops
The following example uses a minimatch pattern to download all .exe 's and dll 's in your Universal Package.
Don't forget to update these values to match the values that you selected when you published your package.
New URLs
Legacy URLs
az artifacts universal download --organization https://dev.azure.com/fabrikam --feed FabrikamFiber --name my-

first-package --version 1.0.0 --path . --file-filter **/*.exe;**/*.dll
Downloading the latest version

When downloading a Universal Package, you can use a wildcard expression in the version parameter to
download the highest version of a package according to Semantic Versioning precedence rules.
Examples
* : Highest version
1.* : Highest version with major version 1
1.2.* : Highest patch release with major version 1 and minor version 2
Wildcard expressions do not currently support pre-release versions. It is not possible to get the latest pre-release
version of a package.
Note that while Semantic Versioning specifies that versions must increase over time, Azure Artifacts does not
enforce this rule. As such, the highest matching version that will be downloaded is not necessarily the most
recently published version.
Next steps
In this quickstart, you published your first Universal Package and then downloaded back to your machine. To learn
more about the Universal Package CLI, append -h to any CLI command.
To use Universal Packages in Azure Pipelines, see the Azure Pipelines doc for Universal Packages or see the full
Universal Packages task documentation.
Publish and download Universal Packages in Azure
Pipelines
Azure Pipelines
When you want to publish a set of related files from a pipeline as a single package, you can use Universal Packages
hosted in Azure Artifacts feeds.
Prepare your Universal Package

Universal Packages are created from a directory of files. By default, the Universal Packages task will publish all files
in $(Build.ArtifactStagingDirectory) .
To prepare your Universal Package for publishing, either configure preceding tasks to place output files in that
directory, or use the Copy Files utility task to assemble the files that you want to publish.

YAML
Classic
To publish a Universal Package to your feed, add the following snippet to your azure-pipelines.yml file.
- task: UniversalPackages@0
displayName: Universal Publish
inputs:
command: publish
publishDirectory: '$(Build.ArtifactStagingDirectory)'
vstsFeedPublish: '<projectName>/<feedName>'
vstsFeedPackagePublish: '<Package name>'
packagePublishDescription: '<Package description>'
A RGUM EN T DESC RIP T IO N
publishDirectory Location of the files to be published.
vstsFeedPublish The project and feed name to publish to.
vstsFeedPackagePublish The package name.
packagePublishDescription Description of the content of the package.
NOTE
See Task control options to learn about the available control options for your task.
feed permissions.
To publish to an external Universal Packages feed, you must first create a service connection to point to that feed.
You can do this by going to Project settings , selecting Ser vice connections , and then creating a New Ser vice
Connection . Select the Team Foundation Ser ver/Team Ser vices option for the service connection. Fill in the
feed URL and a personal access token to connect to the feed.
Package versioning
In Universal Packages, a particular package is identified by its name and version number. Currently, Universal
Packages require Semantic Versioning. Semantic version numbers have three numeric components,
Major.Minor.Patch . When you fix a bug, you increment the patch ( 1.0.0 to 1.0.1 ). When you release a new
backward-compatible feature, you increment the minor version and reset the patch version to 0 ( 1.4.17 to 1.5.0
). When you make a backward-incompatible change, you increment the major version and reset the minor and
patch versions to 0 ( 2.6.5 to 3.0.0 ).
The Universal Packages task automatically selects the next major, minor, or patch version for you when you publish
a new package. Just set the appropriate option.
YAML
Classic
In the Universal Packages snippet that you added previously, add a versionOption . The options for publishing a
new package version are: major , minor , patch , or custom .
Selecting custom allows you to specify any SemVer2 compliant version number for your package. The other
options will get the latest version of the package from your feed and increment the chosen version segment by 1.
So if you have a testPackage v1.0.0, and you publish a new version of testPackage and select the major option, your
package version number will be 2.0.0. If you select the minor option, your package version will be 1.1.0, and if you
select the patch option, your package version will be 1.0.1.
One thing to keep in mind is that if you select the custom option, you must also provide a versionPublish .
displayName: Universal Publish
inputs:
command: publish
publishDirectory: '$(Build.ArtifactStagingDirectory)'
vstsFeedPublish: '<projectName>/<feedName>'
vstsFeedPackagePublish: '<Package name>'
versionOption: custom
versionPublish: '<Package version>'
packagePublishDescription: '<Package description>'
publishDirectory Location of the files to be published.
vstsFeedPublish The project and feed name to publish to.
vstsFeedPackagePublish The package name.
versionOption Select a version increment strategy. Options: major , minor ,

patch , custom
versionPublish The custom package version
packagePublishDescription Description of the content of the package.
NOTE
Download a Universal Package

You can also download a Universal Package from your pipeline.
YAML
Classic
To download a Universal Package from a feed in your organization to a specified destination, use the following
snippet:
steps:
displayName: 'Universal download'
inputs:
command: download
vstsFeed: '<projectName>/<feedName>'
vstsFeedPackage: '<packageName>'
vstsPackageVersion: 1.0.0
downloadDirectory: '$(Build.SourcesDirectory)\someFolder'
vstsFeed The project and feed name that the package will be
downloaded from.
vstsFeedPackage Name of the package to be downloaded.
vstsPackageVersion Version of the package to be downloaded.
downloadDirectory Package destination directory. Default is

$(System.DefaultWorkingDirectory).
NOTE
To download a Universal Package from an external source, use the following snippet:
steps:
displayName: 'Universal download'
inputs:
command: download
feedsToUse: external
externalFeedCredentials: MSENG2
feedDownloadExternal: 'fabrikamFeedExternal'
packageDownloadExternal: 'fabrikam-package'
versionDownloadExternal: 1.0.0
feedsToUse Value should be external when you're downloading from an

external source.
externalFeedCredentials Name of a service connection to another Azure DevOps

organization or server. See service connections.
feedDownloadExternal Feed that the package will be downloaded from.
packageDownloadExternal Name of the package to be downloaded.
versionDownloadExternal Version of the package to be downloaded.
NOTE
Downloading the latest version

You can use a wildcard expression as the version to get the latest (highest) version of a package. For more
information, see Downloading the latest version in the quickstart guide.
FAQ
Where can I learn more about Azure Artifacts and the TFS Package Management service?
Package Management in Azure Artifacts and TFS
In what versions of Azure DevOps/TFS are Universal Packages available?
Universal Packages are only available for Azure DevOps Services.
Install a Maven artifact using Gradle in an Azure
DevOps Services build

Gradle is a popular build tool for Java applications and the primary build tool for Android. Learn how to download
a Maven artifact using Gradle during an Azure DevOps Services build of your application.
Prerequisites
Before you start, install the Gradle build tool. Note that Gradle itself requires a prior installation of the Java JDK or
JRE (version 7 or later). You can get the Java JDK here.
From a command prompt, verify that you have the Java JDK or JRE version 7 or later:
java -version
And then install Gradle. Once it completes, confirm the installation from a command prompt:
gradle -v
You're ready to start! This tutorial will guide you through the process of installing a Maven artifact using Gradle.
NOTE
This topic assumes you have cloned your Git repo to your local machine. If you aren't sure how to clone your repo, read
Clone a repo.
First, you need a gradle.proper ties file that contains an Azure DevOps Services credential token.
Navigate to https://dev.azure.com/{yourOrganization}/_usersSettings/tokens , where {yourOrganization} is the
name of your organization.
Click + New Token .
Give your token a name, duration, and select the Packaging (read and write) scope.
You may have to choose "Show all scopes" at the bottom to see the Packaging area.
Click Create .
Navigate to https://dev.azure.com/{yourOrganization}/_usersSettings/tokens , where {yourOrganization} is the
name of your organization.
Click Add .
Give your new token a name and a duration.

Select the Packaging (read and write) scope.
The token will be a long alphanumeric string, like "lzitaoxppojf6smpl2cxdoxybepfxfetjvtkmcpw3o6u2smgebfa".
Copy this string and treat it securely.
Now, go to the folder under the Gradle installation root directory. Typically, this is
.gradle
%INSTALLPATH%/gradle/user/home/.gradle/ . In that folder, create a file named gradle.proper ties .
Open the gradle.proper ties file with a UTF-8-capable text editor and add the following:
vstsMavenAccessToken=YOUR_TOKEN_HERE
Where YOUR_TOKEN_HERE is the token string you created previously. Save the file when you're done.
Install a Maven artifact using Gradle

Open your build.gradle file and confirm that the following text is present at the top of it:
apply plugin: 'java'
Now, add the following code to the end of your build.gradle file. Use the groupId , artifactId , and version you
supplied in the previous step.
dependencies {
compile(group: '{your-group-ID-here}', name: '{your-artifact-ID-here}', version: '{your-version-number-
here}')
}
For example: `compile(group: 'siteOps', name: 'odata-wrappers', version: '1.0.0.0')

This tells gradle build to download the artifact you created prior, which is effectively named orgId:artifactId ,
and that it should be applied to the app named in the dependencies.
To test this, create a simple Java code file and build it with Gradle. You can use this code to test:
package
public class HelloWorld {

public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
Build the code by running Gradle from a command prompt:
gradle build
If the build is successful, you will see BUILD SUCCESSFUL displayed when it completes.
Configure your build to install Maven artifacts using Gradle

Run the following from a command prompt:
gradle wrapper
The Gradle wrapper is created in the directory where you ran the above command. The wrapper's file name is
gradlew . Do not rename this file.
git push an update that contains the wrapper (gradlew) from your cloned (local) repo to origin . Team Build
requires this file on the remote repo for Gradle to build your project.
Go to the Build and Release page for your project, and then select Builds .
Select the + New button. Scroll down and select the Gradle template.
Select Apply to start configuring the build to use your Gradle wrapper.
Now, select the gradlew build step. You can use the default settings to start.
Here, you can configure various Gradle tasks to run during the build. Once you've configured the build pipeline,
click Save & queue from the top menu and start building with your Gradle wrapper. You're done!
Publish a Maven artifact using Gradle

This topic covers creating and publishing a Maven artifact with Gradle using Azure DevOps Services.
Prerequisites
Before you start, make sure you have the Gradle build tool installed.
Note that Gradle itself requires a prior installation of the Java JDK or JRE (version 7 or later). If you don't have it
already, you can get the Java JDK from this link: Java SE Downloads.
To verify that you have the Java JDK or JRE version 7 or later installed, run the following command in an elevated
command prompt:
java -version
If the above command returns a java version then you can now install Gradle, otherwise go back and install Java
JDK or JRE first.
Once Gradle installation is complete, you can confirm the installation with the following command:
gradle -v
You're ready to start! This tutorial will guide you through the process of publishing a Maven artifact using Gradle.
NOTE
This topic assumes you have cloned your Git repo to your local machine. If you aren't sure how to clone your repo, read
Clone an existing Git repo.
First, you need a gradle.proper ties file that contains an Azure DevOps Services credential token.
1. Navigate to https://dev.azure.com/{yourOrganization}/_usersSettings/tokens , where {yourOrganization} is
the name of your organization.
2. Click New Token .
Give your token a name, duration, and select the Packaging (read and write) scope.
NOTE
You may have to choose "Show all scopes" at the bottom to see the Packaging area.
1. Click Create .
1. Navigate to https://dev.azure.com/{yourOrganization}/_usersSettings/tokens , where {yourOrganization} is
the name of your organization.
2. Click Add .
1. Give your new token a name and a duration.

2. Select the Packaging (read and write) scope.
1. Copy your token and save it in a secure location. The token will be a long alphanumeric string, something
like "lzitaoxppojf6smpl2cxdoxybepfxfetjvtkmcpw3o6u2smgebfa".
2. Create a text file and name it: gradle.proper ties in your .gradle folder under the Gradle installation root
directory. Typically, the path to your gradle folder is: %INSTALLPATH%/gradle/user/home/.gradle/ .
3. Open the gradle.proper ties file with a UTF-8-capable text editor and add the following:
vstsMavenAccessToken=<PASTE_YOUR_TOKEN_HERE>
1. Replace <PASTE_YOUR_TOKEN_HERE> with the token you created earlier. Save the file when you're done.
Configure build.gradle
1. Create a text file and name it build.gradle in the root of your cloned repo.
2. Open it with a text editor and add the following snippet:
apply plugin: 'java'
apply plugin: 'maven-publish'
publishing {
publications {
myPublication(MavenPublication) {
groupId '{your-group-ID-here}'
artifactId '{your-artifact-id-here}'
version '{your-version-number-here}'
artifact '{path-to-your-JAR-file-here}'
}
}
// Repositories *to* which Gradle can publish artifacts

repositories {
maven {
url 'https://pkgs.dev.azure.com/{yourOrganizationName}/_packaging/{yourProjectName}'
credentials {
username "Azure DevOps Services"
//The Azure DevOps Services build system will use the "SYSTEM_ACCESSTOKEN" to authenticate to
Azure DevOps Services feeds
password System.getenv("AZURE_ARTIFACTS_ENV_ACCESS_TOKEN") != null ?
System.getenv("AZURE_ARTIFACTS_ENV_ACCESS_TOKEN") : vstsMavenAccessToken
}
}
}
}
// Repositories *from* which Gradle can download dependencies; it's the same as above in this example
repositories {
maven {
url 'https://pkgs.dev.azure.com/{yourOrganizationName}/_packaging/{yourProjectName}'
credentials {
username "Azure DevOps Services"
//The Azure DevOps Services build system will use the "SYSTEM_ACCESSTOKEN" to authenticate to Azure
DevOps Services feeds
password System.getenv("AZURE_ARTIFACTS_ENV_ACCESS_TOKEN") != null ?
System.getenv("AZURE_ARTIFACTS_ENV_ACCESS_TOKEN") : vstsMavenAccessToken
}
}
}
In the above example, you are publishing artifacts and downloading dependent artifacts from the same
organization. You can configure publishing and downloading to use separate organizations, if you prefer.
NOTE
You can use the Azure Artifacts connect to feed dialog box to copy the maven repository section to use in your build.gradle
file.
1. Replace the following fields with your own values:

groupId : A group ID you associate with your package. Give it a team or organization name so consumers can
identify the origin easier.
artifactId : your artifact ID number that will be used when publishing your package. Again, give it a
meaningful name that specifies the package type and version for example.
version : Your package version. This number should be incremented for future iterations.
artifact : Your .jar file path. Example: ./target/myJavaClasses.jar .
Publish your Maven package with Gradle

Run the following command in an elevated command prompt:
gradle publish
Your new package will be named: groupId:artifactId and should show up in your Artifacts feed.
Symbol files (PDBs)
NOTE
A symbol server is available with Azure Ar tifacts in Azure DevOps Services and works best with Visual Studio 2017
Update 4 or later . Team Foundation Ser ver users and users without the Azure Ar tifacts extension can publish
symbols to a file share using a build task.
To debug compiled executables, especially executables compiled from native code languages like C++, you need
symbol files that contain debugging information. These files generally have the PDB (program database) extension.
What's in a symbol file

Symbols contain a set of useful debugging information, including:
publics and exports
global symbols
local symbols
type data
source indexes
line numbers
Publishing symbol files

To allow your users to debug your application, you need to publish your symbol files to a Symbol Server, like the
one provided by Azure Artifacts in Azure DevOps Services.
Consuming symbol files

Once you've published your symbol files, users can use them in the debugging process in Visual Studio or
WinDbg. The debugger will find the appropriate symbols using a unique ID that identifies the symbols associated
with the binary.
Using symbols with NuGet packages

If you publish your application's executables via NuGet packages, there are two ways to share symbols with your
users. NuGet can make symbols packages, which are denoted by a .snupkg extension, but these packages are only
needed if you're publishing symbols to SymbolSource.org or another external symbol host.
Sharing private symbols with Symbol Server
If you're publishing packages to Azure Artifacts, there's no need to use NuGet symbols packages. Instead, configure
the Index Sources and Publish Symbols task in Team Build using the walkthrough.
Sharing public symbols on SymbolSource.org
If you're publishing your packages to NuGet.org, you can publish corresponding symbols packages to
SymbolSource.org. If you're using the NuGet or .NET Core tasks in Team Build, check Create symbols package to
create a symbol package when you pack your executables.
Learn more
To learn more about symbols, see the Windows documentation.
Debug with symbols in Visual Studio
NOTE
Symbol servers enable debuggers to automatically retrieve the correct symbol files without knowing product
names, build numbers or package names. These files contain useful information for the debugger and generally
have the PDB extension.
Add the symbol server to Visual Studio

To debug with symbols, select and add the Azure DevOps Services symbol server to your Visual Studio
environment.
1. Select Tools , then Options , then Debugging .
2. Select Symbols and select the + sign to add a new Azure DevOps symbol server location.
3. In the Connect to Azure DevOps Symbol Ser ver dialog, select your account from the dropdown menu,
then select the organization that you wish to connect to. Select Connect to connect to the symbol server.
4. Your symbol server is added to the list of symbol file locations.
Debugging optimized modules

If you're debugging an optimized module (e.g. something that was built with the Release configuration) and you
haven't modified the default Enable Just My Code setting, Visual Studio will not automatically fetch symbols for
the optimized module.
To debug the module, you can either:
Open the Modules window, right-click and select Load Symbols (recommended).
Select Tools then Options . Select Debugging in the right panel then chose General . uncheck Enable Just
My Code .
Source Link support

We recommend enabling source link support to step into source code. To do so, check Enable Source Link
suppor t under Options > Debugging > General. By default Source Link support is enabled in Visual Studio.
If you choose to enable source server support, please consider the security implications before doing so.
Portable PDBs and Source Link
If you're using Portable PDBs, Source Link does not support authenticating to private source repositories like
Azure DevOps Services. See Source Link diagnostics for more details.
What's next?
Symbol files.
Publish symbols for debugging.
Debug with symbols in WinDbg.
Debug with symbols in WinDbg
NOTE
names, build numbers or package names. To learn more about symbols, read the concept page; to publish
symbols, see this page. To use symbols in Visual Studio, see this page.
Ensure WinDbg can find tf.exe

1. Open C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\srcsrv.ini
2. Ensure that it contains the following content:
[trusted commands]
tf.exe="CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe"
Add the symbol server to WinDbg

To use the Azure DevOps Services symbol server in WinDbg, you'll add your organization to the symbol search
path.
1. Open WinDbg (you can install it from the Store).
2. Load the executable you wish to debug.
3. Copy this command and replace <yourOrg> with your Azure DevOps Services account name:
.sympath+ https://artifacts.dev.azure.com/<yourOrg>/_apis/symbol/symsrv
4. In the Command window in WinDbg, enter the command from the previous step
5. Set a breakpoint ( bp ), which will cause WinDbg to issue a symbols request
6. Create a Personal Access Token with the Symbols (read) scope and copy it to your clipboard
7. In the authentication prompt that appears, leave the username blank and enter your PAT from the previous step
as the password
WinDbg should then acquire symbols for your executable. You can run lm to confirm.
Publish symbols for debugging
Azure Pipelines | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 - TFS 2015
NOTE
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions,
runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called
phases.
NOTE
names, build numbers, or package names. To learn more about symbols, read the concept page. To consume
symbols, see this page for Visual Studio or this page for WinDbg.
Publish symbols
To publish symbols to the symbol server in Azure Artifacts, include the Index Sources and Publish Symbols task
in your build pipeline. Configure the task as follows:
For Version , select 2.\ *.
For Symbol Ser ver Type , select Symbol Ser ver in this organization/collection (requires Azure
Ar tifacts) .
Use the Path to symbols folder argument to specify the root directory that contains the .pdb files to be
published.
Use the Search pattern argument to specify search criteria to find the .pdb files in the folder that you specify
in Path to symbols folder . You can use a single-folder wildcard ( * ) and recursive wildcards ( ** ). For
example, **\bin\**\*.pdb searches for all .pdb files in all subdirectories named bin.
Publish symbols for NuGet packages
To publish symbols for NuGet packages, include the preceding task in the build pipeline that produces the NuGet
packages. Then the symbols will be available to all users in the Azure DevOps organization.
Publish symbols to a file share

You can also publish symbols to a file share by using the Index Sources and Publish Symbols task. When you use
this method, the task will copy the .pdb files over and put them into a specific layout. When Visual Studio is
pointed to the UNC share, it can find the symbols related to the binaries that are currently loaded.
Add the task to your build pipeline and configure it as follows:
For Symbol Ser ver Type , select File share .
When you select File share as Symbol Ser ver Type , you get the Compress Symbols option. This
option compresses your symbols to save space.
Use the Path to symbols folder argument to specify the root directory that contains the .pdb files to be
published.
Use the Search pattern argument to specify search criteria to find the .pdb files in the folder that you specify
in Path to symbols folder . You can use a single-folder wildcard ( * ) and recursive wildcards ( ** ). For
example, **\bin\**\*.pdb searches for all .pdb files in all subdirectories named bin.
Portable PDBs
If you're using portable PDBs, you still need to use the Index Sources and Publish Symbols task to publish
symbols. For portable PDBs, the build does the indexing, however you should use SourceLink to index the
symbols as part of the build. Note that Azure Artifacts doesn't presently support ingesting NuGet symbol
packages and so the task is used to publish the generated PDB files into the symbols service directly.
Use indexed symbols to debug your app

You can use your indexed symbols to debug an app on a different machine from where the sources were built.
Enable your development machine
In Visual Studio, you might need to enable the following two options in Debug > Options > Debugging >
General :
Enable source ser ver suppor t
Allow source ser ver for par tial trust assemblies (Managed only)
Advanced usage: overriding at debug time
The mapping information injected into the .pdb files contains variables that can be overridden at debugging time.
Overriding the variables might be required if the collection URL has changed. When you're overriding the
mapping information, the goals are to construct:
A command (SRCSRVCMD) that the debugger can use to retrieve the source file from the server.
A location (SRCSRVTRG) where the debugger can find the retrieved source file.
The mapping information might look something like the following:
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_TARGET=%targ%\%var5%\%fnvar%(%var6%)%fnbksl%(%var7%)
TFS_EXTRACT_CMD=tf.exe git view /collection:%fnvar%(%var2%) /teamproject:"%fnvar%(%var3%)"
/repository:"%fnvar%(%var4%)" /commitId:%fnvar%(%var5%) /path:"%var7%" /output:%SRCSRVTRG% %fnvar%(%var8%)
TFS_COLLECTION=http://SERVER:8080/tfs/DefaultCollection
TFS_TEAM_PROJECT=93fc2e4d-0f0f-4e40-9825-01326191395d
TFS_REPO=647ed0e6-43d2-4e3d-b8bf-2885476e9c44
TFS_COMMIT=3a9910862e22f442cd56ff280b43dd544d1ee8c9
TFS_SHORT_COMMIT=3a991086
TFS_APPLY_FILTERS=/applyfilters
SRCSRVVERCTRL=git
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
SRCSRVTRG=%TFS_EXTRACT_TARGET%
SRCSRVCMD=%TFS_EXTRACT_CMD%
SRCSRV: source files ---------------------------------------
C:\BuildAgent\_work\1\src\MyApp\Program.cs*TFS_COLLECTION*TFS_TEAM_PROJECT*TFS_REPO*TFS_COMMIT*TFS_SHORT_COM
MIT*/MyApp/Program.cs*TFS_APPLY_FILTERS
C:\BuildAgent\_work\1\src\MyApp\SomeHelper.cs*TFS_COLLECTION*TFS_TEAM_PROJECT*TFS_REPO*TFS_COMMIT*TFS_SHORT_
COMMIT*/MyApp/SomeHelper.cs*TFS_APPLY_FILTERS
The preceding example contains two sections: the variables section and the source files section. The information
in the variables section can be overridden. The variables can use other variables, and can use information from
the source files section.
To override one or more of the variables while debugging with Visual Studio, create an .ini file
%LOCALAPPDATA%\SourceServer\srcsrv.ini . Set the content of the .ini file to override the variables. For example:
[variables]
TFS_COLLECTION=http://DIFFERENT_SERVER:8080/tfs/DifferentCollection
IMPORTANT
If you want to delete symbols that were published using the Index Sources & Publish Symbols task, you must first
remove the build that generated those symbols. This can be accomplished by using retention policies to clean up your
build or by manually deleting the run. For more information about debugging your app, see Debug with symbols in Visual
Studio, and Debug with symbols in WinDbg.
FAQ
Q: What's the retention policy for the symbols stored in the Azure Pipelines symbol server?
A: Symbols have the same retention as the build. When you delete a build, you also delete the symbols that the
build produced.
Q: Can I use source indexing on a portable .pdb file created from a .NET Core assembly?
A: No, source indexing is currently not enabled for portable .pdb files because SourceLink doesn't support
authenticated source repositories. The workaround at the moment is to configure the build to generate full .pdb
files.
Q: Is this available in TFS?
A: In TFS, you can bring your own file share and set it up as a symbol server, as described in this blog.
Use Index Sources & Publish Symbols task to publish
your symbols
Symbols are PDB files that are generated after a successful build run. these files are used by developers to debug
their application. Azure Artifacts now offers a dedicated symbols server to publish your symbols.
The Publish symbols feature is part of the Index Sources & Publish Symbols task. This feature is also available
for GitHub repositories.
To publish your symbols check the Publish symbols checkbox and select the Symbol Ser ver in this
account/collection option from the dropdown.
Using Source Link in .NET projects

Source link is a set of tools that allow developers to debug their source code by mapping from the .NET assemblies
back to the source code.
For projects hosted on GitHub, add the Microsoft.SourceLink.GitHub package reference to your project file.
<ItemGroup>
<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0" PrivateAssets="All"/>
</ItemGroup>
For projects hosted on Azure Repos, add the Microsoft.SourceLink.AzureRepos.Git package reference to your
project file.
<ItemGroup>
<PackageReference Include="Microsoft.SourceLink.AzureRepos.Git" Version="1.0.0" PrivateAssets="All"/>
</ItemGroup>
Modifying the Build Pipeline

The next step is to modify the build pipeline to invoke Source Link during the build process. To do so, add
/p:SourceLinkCreate=true to the MSBuild arguments field within the Visual Studio Build task.
Select Save & queue to save and run your build pipeline when an agent is available.
Set up Visual Studio

Once the build has been completed and the symbols published, it is time to make sure that everything is working
properly. But first, we must ensure that Visual Studio is set up properly.
1. Select Tools then Options .
2. Under Debugging , select Symbols .
3. Select the + sign to add a new symbol file location then type your URL.
4. Select General under the same section. Scroll down and check Enable Source Link suppor t .
Verifying the Setup

Now that Visual Studio is configured, it is time to attach the debugger to the process you want to debug. Once the
debugger is attached Visual Studio will establish connection to the symbols server and attempt to locate the
symbols.
The first time Visual Studio attempts to download the source code it will prompt the user for input.
Visual Studio will then download the file(s) needed and launch the code editor at a break point.
TIP
When attaching to a process, you may need to uncheck the Enable Just My Code option. See Enable or disable Just My
Code for details.
Related articles
Publish Symbols for Debugging
Build: Index & Publish Symbols

Azure Artifacts in Azure DevOps PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Azure Artifacts in Azure DevOps PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Contents

Azure Artifacts Documentation

Azure Artifacts overview

Get started with using Azure Artifacts

Versions and compatibility

F EAT URE A Z URE DEVO P S SERVIC ES T FS

NuGet Yes TFS 2017 and newer

npm Yes TFS 2017 Update 1 and newer

NuGet.org upstream source Yes TFS 2018 Update 2 and newer

Maven Yes TFS 2018 and newer

Python Yes Azure DevOps Server 2019 Update 1

Universal Packages Yes No

Other package types

Azure DevOps Ser vices

Install Azure Artifacts in TFS

Assign licenses in TFS

Billing and free monthly usage

View artifact and billed storage

Pay for Azure Artifacts

Azure DevOps Ser vices

How to find your packages in Azure DevOps Services

Azure Artifacts billing model

Creating packages as part of a build

Consuming packages from public and internal sources as part of a build

Azure DevOps Ser vices | TFS 2017 (availability note)

How upstreams construct the set of available packages

Example: constructing the set of available packages

Azure DevOps Ser vices | TFS 2017

Components and composition

What should you use

Project-scoped feeds vs. Organization-scoped feeds

Restoring a deleted feed

2. Select Feed Settings .

3. Select Restore Feed .

2. Select Permanently delete and confirm the deletion

Understanding the difference between an organization-scoped feed

What can I do if I'm concerned about my project-scoped feed's visibility

Views and upstream sources

Using views to release packages

Azure DevOps Ser vices

Create a PAT to get command-line access to Azure DevOps Services

Create the feed

2. Select Create Feed

Creating, packaging, and sending a module

New-ModuleManifest -Path .\Get-Hello.psd1

Package and publish the module

nuget spec Get-Hello

nuget pack Get-Hello.nuspec

Add the new package source to your NuGet configuration file:

nuget sources Add -Name "PowershellModules" -Source

nuget sources Add -Name "PowershellModules" -Source

Publish the NuGet package to your feed:

Our PowerShell module is now available in our feed.

Connecting to the feed as a PowerShell repo

$patToken = "YOUR PERSONAL ACCESS TOKEN" | ConvertTo-SecureString -AsPlainText -Force

$credsAzureDevopsServices = New-Object System.Management.Automation.PSCredential("YOUR EMAIL",

Register-PSRepository -Name "PowershellAzureDevopsServices" -SourceLocation

Register-PSRepository -Name "PowershellAzureDevopsServices" -SourceLocation

5. Find modules in our repository:

Find-Module -Repository PowershellAzureDevopsServices

Install-Module -Name Get-Hello -Repository PowershellAzureDevopsServices

Get-Module -ListAvailable Get-Hello

2. Select + New public feed :