This post was most recently updated on September 12th, 2021.
3 min read.Let’s go with a very simple “note-to-self” kind of a blog post today. Plenty of those to go around on this blog, and I am sure that there will be plenty more!
This one is another case that should be really obvious, but isn’t, and should just work, but doesn’t. Namely, when you have run a pipeline in Azure DevOps expecting it to publish a package in your internal NuGet feed so that all of your friends can use it.
And Azure DevOps is great for just this, as it has a very handy package feed functionality under “Artifacts” section – an internal feed, to which it’s really easy to package and build your Nuget package to.
This article is not going to go into the details of packaging and publishing a package. Instead, let’s presume that you have a build that’s supposed to publish a new NuGet package, and that stuff actually works… But you’re actually experiencing issues trying to access your newly published package.
Problem
So let’s recap:
Do you want to access your package in the Azure DevOps artifact feed? Sure thing – easy! Just build and publish with the “NuGetCommand@2 pack“, and you’re good!
However, it might take any number of minutes for your package to show up in the UI – the longest I’ve seen has been around 30 minutes. And even longer for the package to show up in the NuGet feed (especially if you can’t even promote your package since you can’t access it!)
But what if you really need to verify the package has the right contents before pushing it to the Prerelease or Release stream – right away?
Solution
Well, luckily you can access the package via the URL even if it’s not available through the UI! Below, I’ll show you how:
Time needed: 2 minutes
- Navigate to Artifacts in Azure DevOps
Simple enough:
Yes, it says “Artifacts”, and it looks like a pile of pink boxes. - Select your package
Search for your package by name and select it from the list.
However, when you access the details of your package, it might show you pretty much any version of the package – not the latest, the latest published, or any other meaningful version. - Observe the Versions of your package
Select “Versions” from the ribbon (or whatever it’s called here):
- Choose a version of your package
In the screenshot below, I can see versions 3.1.4 and 3.2.0 – but not 3.1.5, which I just published (as a hotfix to 3.1 branch, while maintaining 3.2 branch as-is) and wanted to access – but can’t.
So, next, we’ll be accessing the new, still unavailable package! - Modify the URL showing the package information
The screenshot below shows what’s in the URL, and what you need to change:
Feed and package names are good – keep them. But you need to change the version number (shown in purple)
https://contoso.visualstudio.com/Contoso Common Code Packages/_packaging?_a=package&feed=CCCP&package=Contoso.Commons.Packaging.Helper&protocolType=NuGet&version=3.2.0&view=overview
I’ll change mine to 3.1.5. And lo and behold, what do I get? - There you go! Do whatever you want with your package version now :)
Nice – there’s the package! It might still take a while to be available through the actual UI, but you can still Download & Promote your package at will!
And boom! You should be good. Another simple but easy-to-screw-up thing documented.
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- CSOM suddenly throwing exceptions when trying to access list contents in SharePoint? A weird fix. - April 2, 2024
- “Predefined type ‘System.Object’ is not defined or imported” and other System namespace stuff missing in your solution? - March 26, 2024
- How to import GraphQL schema to Postman in Windows? - March 19, 2024
