Professional Documents
Culture Documents
Azure Artifacts in Azure DevOps PDF
Azure Artifacts in Azure DevOps PDF
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.
Maven Central upstream source Yes Azure DevOps Server 2019 Update 1
and newer, Azure DevOps Server 2020
Azure DevOps Ser vices | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 - TFS
2017
NOTE
If you're using a version of TFS, you need to license Azure Artifacts rather than 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.
NOTE
If the Azure Artifacts extension has been removed, you can install it from the Marketplace page for Azure Artifacts.
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.
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.
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.
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
2/26/2020 • 2 minutes to read • Edit Online
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
11/2/2020 • 2 minutes to read • Edit Online
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 DevOps Ser vices | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 - TFS
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
11/2/2020 • 2 minutes to read • Edit Online
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).
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.
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
2/26/2020 • 2 minutes to read • Edit Online
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
2/26/2020 • 5 minutes to read • Edit Online
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.
Jump in
If you're ready to get started with package componentization, check out the Azure Artifacts overview.
Limits
2/26/2020 • 2 minutes to read • Edit Online
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
11/2/2020 • 2 minutes to read • Edit Online
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?
11/2/2020 • 3 minutes to read • Edit Online
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.
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
Enabling upstream sources allow you to use your favorite OSS packages and gives you more protection against
outages and corrupted or compromised packages.
See Set feeds and views permissions to learn more about managing your feeds.
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
11/2/2020 • 2 minutes to read • Edit Online
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.
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.
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?
11/2/2020 • 3 minutes to read • Edit Online
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.
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.
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.
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.
|--- 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.
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')
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:
If you're still using the older visualstudio.com URLs, use the following command instead:
nuget push -Source "PowershellModules" -ApiKey AzureDevOpsServices "your .nupkg path. eg: .\Get-
Hello.1.0.0.nupkg"
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.
IMPORTANT
PowerShell does not support Version 3 of NuGet.
If you're still using the older visualstudio.com URLs, use the following command instead:
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
Our Get-Hello module should be one of the entries in the previous cmdlet's return message. To install it,
run the following command:
You can check for your module by running the following command:
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
4/29/2020 • 2 minutes to read • Edit Online
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:
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
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
11/2/2020 • 3 minutes to read • Edit Online
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
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
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.
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.
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
11/2/2020 • 2 minutes to read • Edit Online
PATCH
https://pkgs.dev.azure.com/{organization}/{project}/_apis/packaging/feeds/{feedId}/nuget/packages/{packageName
}/versions/{packageVersion}?api-version=5.1-preview.1
PATCH
https://pkgs.dev.azure.com/{organization}/_apis/packaging/feeds/{feedId}/npm/{packageName}/versions/{packageVe
rsion}?api-version=5.1-preview.1
PATCH
https://pkgs.dev.azure.com/{organization}/{project}/_apis/packaging/feeds/{feedId}/pypi/packages/{packageName}
/versions/{packageVersion}?api-version=5.1-preview.1
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).
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.
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.
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
11/2/2020 • 5 minutes to read • Edit Online
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.
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:
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
11/2/2020 • 4 minutes to read • Edit Online
List and ✓ ✓ ✓ ✓
restore/install
packages
Push packages ✓ ✓
Unlist/deprecate ✓ ✓
packages
Promote a package ✓ ✓
to a view
Delete/unpublish ✓
package
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.
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.).
Select Permissions .
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.
Azure DevOps Ser vices | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 | TFS
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.
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
Saving can improve download performance and save network bandwidth, esp. for TFS servers located on
internal networks.
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.
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.
IMPORTANT
Maven snapshot artifacts are not currently supported in upstream sources.
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 .
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 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.
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.
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
11/2/2020 • 5 minutes to read • Edit Online
Azure DevOps Ser vices | Azure DevOps Ser ver 2020 | Azure DevOps Ser ver 2019 | TFS 2018 | TFS
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.
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.
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.
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 .
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
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.
1. Go to Azure Ar tifacts .
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
Enabling upstream sources allow you to use your favorite OSS packages and gives you more protection against
outages and corrupted or compromised packages.
See Set feeds and views permissions to learn more about managing your feeds.
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. 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.
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)>
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)>
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.
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 .
6. If you enabled the nuget.org upstream source, clear the check box for the nuget.org package source.
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.
What's next?
For more advanced topics, check out the content summary.
Publish to NuGet feeds (YAML/Classic)
11/2/2020 • 8 minutes to read • Edit Online
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.
- 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:
- task: NuGetCommand@2
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
For a list of other possible values for versioningScheme , see the NuGet task.
YAML is not supported in TFS.
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)'
steps:
- task: NuGetAuthenticate@0
displayName: 'NuGet Authenticate'
- task: NuGetCommand@2
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>'
- task: NuGetCommand@2
inputs:
command: push
nuGetFeedType: external
versioningScheme: byEnvVar
versionEnvVar: <VersionVariableName>
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
11/2/2020 • 3 minutes to read • Edit Online
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:
1. Go to your feed (or create a feed if you haven't).
2. Select Connect to feed :
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.
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)>
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)>
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.
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 .
6. If you enabled the nuget.org upstream source, clear the check box for the nuget.org package source.
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.
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.
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.
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}
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}
On developer machines
1. Navigate to your feed (or create a feed if you haven't).
2. Select Connect to feed :
nuget sources add -name {your feed name} -source {your feed URL} -username {your domain username} -password
{your domain password}
Use packages from nuget.org
11/2/2020 • 2 minutes to read • Edit Online
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.
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.
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 ).
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
11/2/2020 • 8 minutes to read • Edit Online
NOTE
If the Azure Artifacts extension has been removed, you can install it from the Marketplace page for Azure Artifacts.
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.
With your feed selected, select the gear icon (on the right side of the page).
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.
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=
[ANY_VALUE_BUT_NOT_AN_EMPTY_STRING]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:_password=
[BASE64_ENCODED_PERSONAL_ACCESS_TOKEN]
//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(); })"
[Convert]::ToBase64String([system.Text.Encoding]::UTF8.GetBytes("YOUR_PAT_GOES_HERE"))
Next steps
Check out the Azure Artifacts landing page to learn about other topics.
Publish npm packages (YAML/Classic)
11/2/2020 • 3 minutes to read • Edit Online
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.
- 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.
YAML is not supported in TFS.
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
11/2/2020 • 2 minutes to read • Edit Online
npm init
npm publish
See the npm publish docs for more information on the publish command.
What's next?
Check out the Azure Artifacts landing page to learn about other topics.
Set up your client's npmrc
11/2/2020 • 8 minutes to read • Edit Online
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.
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
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.
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=
[ANY_VALUE_BUT_NOT_AN_EMPTY_STRING]
//pkgs.dev.azure.com/<yourOrganization>/_packaging/<yourFeed>/npm/:_password=
[BASE64_ENCODED_PERSONAL_ACCESS_TOKEN]
//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(); })"
[Convert]::ToBase64String([system.Text.Encoding]::UTF8.GetBytes("YOUR_PAT_GOES_HERE"))
@[YOUR_SCOPE]/registry=FabrikamBasic/_packaging/FabrikamFeed/npm/registry/
To restore your packages, run the following command in your project directory:
npm install
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.
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 .
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.
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.
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 Authenticate task from the list, and then choose Add .
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 .
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
11/7/2020 • 2 minutes to read • Edit Online
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
6/12/2020 • 3 minutes to read • Edit Online
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.
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.
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(); })"
[Convert]::ToBase64String([system.Text.Encoding]::UTF8.GetBytes("YOUR_PAT_GOES_HERE"))
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" } .
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.
steps:
- task: Npm@1
displayName: 'npm custom'
inputs:
command: custom
verbose: false
customCommand: 'audit --registry=https://registry.npmjs.org/'
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.
1. Go to Azure Ar tifacts .
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
Enabling upstream sources allow you to use your favorite OSS packages and gives you more protection against
outages and corrupted or compromised packages.
See Set feeds and views permissions to learn more about managing your feeds.
Set up authentication
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 .
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 build
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.
IMPORTANT
Maven snapshot artifacts are not currently supported in upstream sources.
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.
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
<dependency> element.
4. Paste the <dependency> element content inside the <dependencies> element of your pom.xml file.
5. Run mvn install from the directory that contains your pom.xml file.
What's next?
Check out the Azure Artifacts landing page to learn about other topics.
Set up Azure Pipelines and Maven
11/2/2020 • 2 minutes to read • Edit Online
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.
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>
<!-- Paste the <server> snippet generated by Azure DevOps here -->
</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:
1. Navigate to Ar tifacts .
2. With your feed selected, select Connect to feed .
3. Select Maven .
<url>https://pkgs.dev.azure.com/[ORGANIZATION_NAME]/_packaging/[ORGANIZATION_NAME]/maven/v1</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</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.
mvn build
mvn deploy
Publish Maven artifacts from the command line
11/2/2020 • 2 minutes to read • Edit Online
mvn build
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.
IMPORTANT
Maven snapshot artifacts are not currently supported in upstream sources.
Set up the Maven client in Azure DevOps Services
and TFS
2/26/2020 • 2 minutes to read • Edit Online
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
2/26/2020 • 2 minutes to read • Edit Online
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.
1. Create a Maven artifact by using the following command:
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
<dependency> element.
4. Paste the <dependency> element content inside the <dependencies> element of your pom.xml file.
5. Run mvn install from the directory that contains your pom.xml file.
See the Maven CLI docs for more installation options.
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>
<!-- Copy this section from the Maven section of the "Connect to Feed" dialog" -->
<repository>
<id>dev.azure.com-mseng-zcalvinmaven</id>
<url>https://dev.azure.com/mseng/_packaging/zCalvinMaven2/maven/v1</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<distributionManagement>
<!-- Copy this section from the Maven section of the "Connect to Feed" dialog" -->
<repository>
<id>dev.azure.com-mseng-zcalvinmaven</id>
<url>https://dev.azure.com/mseng/_packaging/zCalvinMaven2/maven/v1</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</distributionManagement>
</project>
IMPORTANT
The <id> tags in the settings.xml and the pom.xml must match.
Use packages from Maven Central
11/2/2020 • 2 minutes to read • Edit Online
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.
To learn more about the concept of upstream sources, please see the concepts page.
IMPORTANT
Maven snapshot artifacts are not currently supported in upstream sources.
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.
NOTE
You can use the Get the tools button to get pip , twine and the ar tifacts keyring .
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
11/2/2020 • 2 minutes to read • Edit Online
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
Check out the script YAML task reference for the schema for this command.
- task: TwineAuthenticate@0
inputs:
artifactFeeds: 'feed_name1, feed_name2'
externalFeeds: 'feed_name1, feed_name2'
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
11/2/2020 • 5 minutes to read • Edit Online
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:
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:
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 :
Next, set the organization that you just logged in to as the CLI's default. Again, replace the item in square brackets.
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
11/2/2020 • 6 minutes to read • Edit Online
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.
- task: UniversalPackages@0
displayName: Universal Publish
inputs:
command: publish
publishDirectory: '$(Build.ArtifactStagingDirectory)'
vstsFeedPublish: '<projectName>/<feedName>'
vstsFeedPackagePublish: '<Package name>'
packagePublishDescription: '<Package description>'
NOTE
See Task control options to learn about the available control options for your task.
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.
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 .
- task: UniversalPackages@0
displayName: Universal Publish
inputs:
command: publish
publishDirectory: '$(Build.ArtifactStagingDirectory)'
vstsFeedPublish: '<projectName>/<feedName>'
vstsFeedPackagePublish: '<Package name>'
versionOption: custom
versionPublish: '<Package version>'
packagePublishDescription: '<Package description>'
NOTE
See Task control options to learn about the available control options for your task.
steps:
- task: UniversalPackages@0
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.
NOTE
See Task control options to learn about the available control options for your task.
To download a Universal Package from an external source, use the following snippet:
steps:
- task: UniversalPackages@0
displayName: 'Universal download'
inputs:
command: download
feedsToUse: external
externalFeedCredentials: MSENG2
feedDownloadExternal: 'fabrikamFeedExternal'
packageDownloadExternal: 'fabrikam-package'
versionDownloadExternal: 1.0.0
NOTE
See Task control options to learn about the available control options for your task.
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
11/2/2020 • 3 minutes to read • Edit Online
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.
Set up authentication
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 .
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.
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}')
}
package
gradle build
If the build is successful, you will see BUILD SUCCESSFUL displayed when it completes.
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
11/2/2020 • 3 minutes to read • Edit Online
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.
Set up authentication
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 .
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 *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.
gradle publish
Your new package will be named: groupId:artifactId and should show up in your Artifacts feed.
Symbol files (PDBs)
11/2/2020 • 2 minutes to read • Edit Online
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.
Learn more
To learn more about symbols, see the Windows documentation.
Debug with symbols in Visual Studio
11/7/2020 • 2 minutes to read • Edit Online
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.
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.
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.
What's next?
Symbol files.
Publish symbols for debugging.
Debug with symbols in WinDbg.
Debug with symbols in WinDbg
11/2/2020 • 2 minutes to read • Edit Online
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.
Symbol servers enable debuggers to automatically retrieve the correct symbol files without knowing product
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.
[trusted commands]
tf.exe="CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe"
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
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.
Symbol servers enable debuggers to automatically retrieve the correct symbol files without knowing product
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 Version , select 1.\ *.
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.
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.
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
11/7/2020 • 2 minutes to read • Edit Online
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.
<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>
Select Save & queue to save and run your build pipeline when an agent is available.
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