Cool huh?Version numbers are something to be mindful of here.
Once a package version number is used that’s it, you can’t reuse it.
That’s good when you think about it… However, if you try and run your build a second time you’ll notice it’ll fail when pushing to the feed.
If you look at the details you’ll see it’s failing because there’s already a package in the feed with that version (1.
0.
0 right?).
To change your version you need to go back to visual studio, project properties, package tab and Package Version.
Updating this to 1.
0.
1, commit and push, will result in a successful build next time.
If you’ve followed the debug instructions below, remember it’s actually the nuspec file that now owns this.
You can of course add CI to your pipeline so you don’t need to manually trigger your builds.
Select Triggers from the top tabs of your pipelines edit screen and on the right hand side tick the Enable Continuous Integration check box.
Now you’ll trigger a new build with every push to your repo.
Great — so we have our package.
It’s in our feed — looking good.
Let’s look at how to consume it!Consuming My PackageOk — let’s create a new solution and project in Visual Studio ready to consume our exciting new compression package.
Once you have your project, right lick your project and select Manage NuGet Packages.
This brings up the nuget page for your project.
On the top right of this page you’ll see Package Sources, which if you drop down you’ll notice your feed isn’t present in.
We need to address this to consume our packages.
Click the cog to the right of the sources drop down to see the configured package sources for your Visual Studio instance.
You need to add your new Azure Artifacts feed so click the plus button, give the feed a meaningful name, then you need the source url.
Jump back to Azure DevOps and select the Artifacts tab on the left.
Now at the top, next to the ‘New Feed’ button we clicked earlier is a Connect To Feed button.
Clicking this will bring up the dialog which contains the Package Source URL you need back in Visual Studio.
Click the handy ‘copy to clipboard’ button, then back to visual studio, paste the value into the Source text box.
And you’re done!You can now drop down the Package Source drop down and you’ll see your new feed.
When you select it, and have browse selected on the left, you’ll see your Compression package appear.
Select it and click install.
That’s all there is to it!Debugging My PackageTo debug your package there are a number of things to do.
However as these packages are only for teams within my organisation I found the simplest thing to do was simply to share the pdb and source code files within the package itself.
This means when someone adds this package to their project, within the .
nuget directory they’ll receive the pdb and source code which enables the attached debugger to automatically step into the packaged code.
Yay!.So, here’s how to:Firstly — Azure is helping us by creating a nuspec file, which tells nuget what the contents of the package should be, what version it is, what dependencies it has etc… Well to put the pdb and source in there too we’ll need to explicitly create and share the nuspec file ourselves instead.
Create a file called compression.
nuspec in the root of your project with the following content.
I’ll explain it right after:As well as adding the nuspec file we also need to reference it from the project file itself.
Right click and edit the project file and add the following line to the top PropertyGroup section:Looking back at the nuspec file, we’re using two main sections:Metadata — this is the details of the package itself.
It contains some mandatory elements which you must enter values for — these are the present elements.
The example also shows the dependencies section.
These are the dependencies of your project, and their versions.
I’ve left examples in there for illustrative purposes but refer to the nuspec guide [LINK] for more information.
This would have been automatically generated for us previously.
The second section is the files sections.
This is where we differ from what would have been previously generated — and rightly so.
We wouldn’t want default behavior of shipping out our source code as well as our dll right?.(although, it’s pretty easy to get back to source code from the binary, sometimes even if it is obfuscated…).
So what’s happening here is we’re saying we want everything from our build output, dlls, pdbs, everything.
We’re also saying we want all of our .
cs files too.
All cs files will now be included in our package.
This includes assemblyInfo which we could write an exclusion for — but to keep this simple I’ve omitted any further complications for now.
The package version here over rules the package version in the project settings.
The nuspec file is now the owner of the package version.
When up versioning your package in the future, you need to change it here.
So if we commit and push our updated csproj file and our new nuspec file (now that we trigger CI builds on our pipeline) we’ll be able to refresh our nuGet packages management screen and see an available update for our compression package.
When we update to that and consume it we’ll be able to debug into the compression code.
Yay!.That’s it!Please see the references section for further details on the various aspects of this post.
Also check out the Microsoft docs for more information about using the Azure Symbol Server if sharing the pdb and source code isn’t right for your situation.
ReferencesMicrosoft docs on consuming nuget packagesNuspec file reference.