Publishing a DotNet tool on NuGet

Have a small utility program? Make it available to download on NuGet

I maintain a small SDK Generator that I use for building C# packages to work with REST APIs. I know there are a million Swagger/OpenAPI generators out there, but I’ve found that most autogenerated SDKs aren’t very usable and I chose to write my own.

Once I had the program working, I decided I’d like to enable it to work as a GitHub Action. The idea would be that you add a workflow file to your SDK repository, and then you can run the action whenever you want. If I can publish my program to NuGet, then the GitHub action can download that file and incorporate it into the script.

Read on for how I published a small command line program to NuGet.

DotNet tools aren’t as beautiful as these, but more useful for GitHub (Wikimedia Commons)

First attempt using DotNet pack

I first found this nice tutorial from 2018. Despite being a bit old, most of the instruction steps in this tutorial are still valid. The important bits are that you need to edit your .csproj file, and then execute a few commands. Here’s what you need to add into your project file:

The next step is to package and publish the library. Here’s how that works:

The end result is that I published a very nice tool to NuGet and you can download it and execute it. However, the end result doesn’t look very appealing. It doesn’t have a readme file or a custom icon or any other information that NuGet packages are expected to have:

The incredibly bare look of a basic DotNet tool

So clearly my next step is to add a readme, add patch notes, add an icon, and so on. The way to do that is with a NuSpec file; let’s try that next.

Adding a NuSpec file to your DotNet tool

I’m familiar with NuSpec files; I publish a few small packages like a CSV library that supports DotNetFramework all the way back to 2.0. But when I tried a basic NuSpec file, it didn’t work. Here’s a list of the changes I had to make to publish this file.

• The dotnet pack command should have the parameter /p:NuspecFile=../../path/to/my.nuspec where the path is relative to the csproj file.
• Instead of bundling files in the /lib/net7.0 folder as you would for a library, your NuSpec file should put the files in the /tools/net7.0/any folder.
• Your NuSpec file needs a new element: <packageTypes><packageType name="DotnetTool"></packageTypes> . Note here that DotNet is spelled “Dotnet” with the N in lowercase — this will become important!
• Add a file to your csproj called DotnetToolSettings.xml — again, note the N is lowercase. If you mess up the casing, your tool won’t work! Here’s what the xml file should contain:

• Make sure your DotnetToolSettings.xml file is configured to copy to the output folder.
• Doublecheck your capitalization! I’m so used to calling it DotNet that I kept mistyping the name, and my package wouldn’t work until I ensured that the N was lowercase.

Once you’ve completed these steps, you can now automate the build and publish for your tool so that anytime you land a commit into the main branch of your git repository it will automatically publish to NuGet. Here’s my final GitHub Action YAML workflow file and my final NuSpec file.

The end result is that my package automatically publishes to NuGet and it has an attractive listing with documentation and comments.

The finished listing on NuGet with readme and documentation

Most importantly, you can now install this program using a simple command from any GitHub action workflow:

Now that the tool publishes correctly, what’s next? My plan is to set up an automated GitHub action workflow that runs once per week and automatically submits a pull request for my SDK anytime my OpenAPI file changes. As we all know, nobody works as hard as a programmer trying to be lazy!

Ted Spence heads engineering at ProjectManager.com and teaches at Bellevue College. If you’re interested in software engineering and business analysis, I’d love to hear from you on Mastodon or LinkedIn.