This is a short post about using Cake to publish packages from Azure Pipelines to Azure Artifacts that took me the better part of a day to figure out. For completness I'll walk through my entire process but if you just want to know how to do it, skip to the end.
In the first part of this series I looked at the overall design of the new libraries and how to set up your environment. In the second part I explained how to search for packages and examined some of the resources provided by the NuGet libraries. In this final part of the series, I'll dive into installing packages. This is a little bit more complicated than the activities in the previous posts because installing a package is actually a much more complex action when you take into account things like current platform and dependency chains.
In the first part of this series I looked at the overall design of the new libraries and how to set up your environment. In this post I'll start to look at implementation details and specifically how to search for packages. The previous caveat still holds, and I could be leading you to use these libraries in a completely inappropriate way. Without documentation, it's hard to say. You've been warned.
The NuGet version 3 libraries have been available for a while, both on GitHub and on the public NuGet gallery. Despite advice by the NuGet team that they aren't ready for public consumption yet, it's been over six months since the first release of NuGet v3 and many packages are starting to require v3 clients for installation. If you already have an application that uses NuGet libraries, this is, or will shortly become, a problem for your application as more and more packages start only supporting the newer client versions.
By now, most .NET developers are at least a bit familiar with NuGet, the NuGet command line interface, and the NuGet GUI in Visual Studio. But did you know there's another way to use NuGet? The project has published libraries (on NuGet, how meta!) for a while. You can reference these libraries from your own code to make your application create packages, download them, extract them, etc. In NuGet version 2, most of the surface API was contained in a library called NuGet.Core. However, the move to NuGet version 3 is bringing some big changes including a transition to many smaller and more granular API libraries. I use the NuGet APIs in some of my own projects and I was wondering how many other projects use them and in what ways. There isn't a lot of documentation on the APIs, so looking at other code is one of the best ways to figure out what works and what doesn't. I was also hopeful it might give me some clues to the future of the NuGet APIs and how best to transition to version 3.
As I prepare to release my first NuGet package, I figured I would provide a walkthrough of how I set all this up. While I’ve used NuGet before (and even set up a private feed for internal libraries at my day job using ProGet, which is awesome), I’ve never published a public package to NuGet.org. While there is ample help available, it can be a little confusing how to rig everything up. I also wanted to enable continuous integration so that every time I committed a change to my library, it would automatically push a new NuGet package.