{"id":4915,"date":"2019-11-03T22:01:18","date_gmt":"2019-11-03T22:01:18","guid":{"rendered":"http:\/\/putridparrot.com\/blog\/?p=4915"},"modified":"2019-11-26T11:33:50","modified_gmt":"2019-11-26T11:33:50","slug":"creating-a-nuget-package-revisited","status":"publish","type":"post","link":"https:\/\/putridparrot.com\/blog\/creating-a-nuget-package-revisited\/","title":{"rendered":"Creating a nuget package (revisited)"},"content":{"rendered":"

I’ve covered some of this post previous in my post Creating Local Packages with NuGet<\/a>, but I wanted to drill down a little more into this here.<\/p>\n

Part of the reason for a revisit is that I wanted to look at creating the relevant .nuspec for a couple of projects I’ve put on github and I wanted to cover the .nuspec files in a little more depth. <\/p>\n

Before we start<\/strong><\/p>\n

Before we start you’ll probably want to grab the latest nuget.exe from Available NuGet Distribution Versions<\/a>. The current recommended version is v4.9.4 and this should be placed in your project folder (or ofcourse wherever you prefer in the path). <\/p>\n

Generating a nuspec file<\/strong><\/p>\n

We can now run <\/p>\n

\r\nnuget spec\r\n<\/pre>\n
in my case, this produced the following<\/p>\n
\r\n<?xml version="1.0"?>\r\n<package >\r\n  <metadata>\r\n    <id>Package<\/id>\r\n    <version>1.0.0<\/version>\r\n    <authors>PutridParrot<\/authors>\r\n    <owners>PutridParrot<\/owners>\r\n    <licenseUrl>http:\/\/LICENSE_URL_HERE_OR_DELETE_THIS_LINE<\/licenseUrl>\r\n    <projectUrl>http:\/\/PROJECT_URL_HERE_OR_DELETE_THIS_LINE<\/projectUrl>\r\n    <iconUrl>http:\/\/ICON_URL_HERE_OR_DELETE_THIS_LINE<\/iconUrl>\r\n    <requireLicenseAcceptance>false<\/requireLicenseAcceptance>\r\n    <description>Package description<\/description>\r\n    <releaseNotes>Summary of changes made in this release of the package.<\/releaseNotes>\r\n    <copyright>Copyright 2019<\/copyright>\r\n    <tags>Tag1 Tag2<\/tags>\r\n    <dependencies>\r\n      <dependency id="SampleDependency" version="1.0" \/>\r\n    <\/dependencies>\r\n  <\/metadata>\r\n<\/package>\r\n<\/pre>\n
As you can see, it’s supplied the basics along with an example of a dependency. The dependencies are the package our project is dependent upon. The id can be found via the nuget website or from the nuget packages section within Visual Studio. The versions can also be found in the same way.<\/p>\n
If we wish to add files to our nuspec we add a files section after the metadata end tag. For example<\/p>\n
\r\n  <\/metadata>\r\n\r\n   <files>\r\n      <file src="" target="" \/>\r\n   <\/files>\r\n\r\n<\/package>\r\n<\/pre>\n
The src<\/em> is the relative location of the files to add (maybe we’re adding a README.txt for example). The target<\/em> is where the file should be copied to. Using content<\/em> as the start of the target will added file to the content folder.<\/p>\n
Naming conventions<\/strong><\/p>\n
The next thing I want to touch on is naming conventions, which I think becomes important if you’re intending the deploy on the NuGet site (as opposed to local to your organization or the likes).<\/p>\n
The Names of Assemblies and DLLs<\/a> discusses some possible conventions. Obviously the <Company>.<Component>.dll is a very sensible convention to adopt as we will need to ensure our assemblies are as uniquely named as possible to stay away from name clashes with others.<\/p>\n
Obviously using such naming conventions will tend to push towards namespace etc. naming conventions also, so have a read of Names of Namespaces<\/a> also.<\/p>\n
Generating our NuGet package from a project<\/strong><\/p>\n
Before we look at the nuspec file itself, let’s cover the simple way of generating our NuGet package, as this might be all you need if the component\/code you want to package is fairly self-contained.<\/p>\n
Before we create the package, let’s create a bare bones .nuspec file because otherwise, the nuget tool will generate one along these lines<\/p>\n
\r\n<?xml version="1.0"?>\r\n<package xmlns="http:\/\/schemas.microsoft.com\/packaging\/2011\/08\/nuspec.xsd">\r\n  <metadata>\r\n    <id>PutridParrot.Collections<\/id>\r\n    <version>1.0.0.0<\/version>\r\n    <title>PutridParrot.Collections<\/title>\r\n    <authors>PutridParrot<\/authors>\r\n    <owners>PutridParrot<\/owners>\r\n    <requireLicenseAcceptance>false<\/requireLicenseAcceptance>\r\n    <description>Description<\/description>\r\n    <copyright>Copyright \u00a9 PutridParrot 2017<\/copyright>\r\n    <dependencies \/>\r\n  <\/metadata>\r\n<\/package>\r\n<\/pre>\n
Note: the project I ran this against was PutridParrot.Collections.csproj<\/em><\/p>\n
So lets take this and change it a little – create a .nuspec named after your project, i.e. mines PutridParrot.Collections.nuspec and paste the below, into it (change names etc. as you need).<\/p>\n
\r\n<?xml version="1.0"?>\r\n<package >\r\n  <metadata>\r\n    <id>Your Project Name<\/id>\r\n    <version>1.0.0.0<\/version>\r\n    <title>Your project title<\/title>\r\n    <authors>Your Name<\/authors>\r\n    <owners>Your Name<\/owners>\r\n    <requireLicenseAcceptance>false<\/requireLicenseAcceptance>\r\n    <description>Your Description<\/description>\r\n    <releaseNotes>First Release<\/releaseNotes>\r\n    <copyright>Copyright 2017<\/copyright>\r\n    <tags>collections<\/tags>\r\n  <\/metadata>\r\n<\/package>\r\n<\/pre>\n
Note: The tags are used by the NuGet repos, so it’s best to come up with several (with a space between each) tags for your project.<\/em><\/p>\n
Now we’ve got a nuspec file this will be embedded into the package by nuget.<\/p>\n
From the command line, (easiest from the folder containing the project you want to package) run<\/p>\n
\r\nnuget pack <project-name>.csproj\r\n<\/pre>\n
Note: as the package is zipped, just append .zip to it to open using File Explorer in Windows, so you can see how it’s laid out. Don’t forget to remove the .zip when relocating to local host of remote host.<\/em><\/p>\n
Autogenerating parts of the nuspec from AssemblyInfo<\/strong><\/p>\n
We can actually tokenize some of our nuspec and have nuget use our project’s AssemblyInfo.cs file, see Replacement tokens<\/a>.<\/p>\n
This means, for example version might be written like this<\/p>\n
\r\n<version>$version$<\/version>\r\n<\/pre>\n
and will have this value automatically replaced and the nupkg will be named with that same version.<\/p>\n
Multiple files or how to use nuget pack with the csproj<\/strong><\/p>\n
Running nuget pack against a project is useful but what if you want to handle multiple projects and\/or non-project files? Then we would be better off editing the nuspec file to pull in the files we want.<\/p>\n
Here’s an example of the previous nuspec which now includes more than one version of the project’s DLL.<\/p>\n
\r\n<?xml version="1.0"?>\r\n<package >\r\n  <metadata>\r\n    <id>Your Project Name<\/id>\r\n    <version>1.0.0.0<\/version>\r\n    <title>Your project title<\/title>\r\n    <authors>Your Name<\/authors>\r\n    <owners>Your Name<\/owners>\r\n    <requireLicenseAcceptance>false<\/requireLicenseAcceptance>\r\n    <description>Your Description<\/description>\r\n    <releaseNotes>First Release<\/releaseNotes>\r\n    <copyright>Copyright 2017<\/copyright>\r\n    <tags>collections<\/tags>\r\n  <\/metadata>\r\n  <files>\r\n    <file src="bin\\Release\\PutridParrot.Collections.dll" target="lib\\net40" \/>\r\n    <file src="bin\\Release\\PutridParrot.Collections.dll" target="lib\\netstandard1.6" \/>\r\n  <\/files>  \r\n<\/package>\r\n<\/pre>\n
Now run<\/p>\n
\r\nnuget pack PutridParrot.Collections.nuspec\r\n<\/pre>\n
Notice we’re running nuget pack against our nuspec file instead and this will bring in two DLL’s and make them available to lib\\net40 and lib\\netstandard1.6 thus targetting two different .NET frameworks.<\/p>\n
The following gives a list of valid Supported frameworks<\/a> that we can assign.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve covered some of this post previous in my post Creating Local Packages with NuGet, but I wanted to drill down a little more into this here. Part of the reason for a revisit is that I wanted to look at creating the relevant .nuspec for a couple of projects I’ve put on github and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[66],"tags":[],"class_list":["post-4915","post","type-post","status-publish","format-standard","hentry","category-nuget"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/4915","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/comments?post=4915"}],"version-history":[{"count":5,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/4915\/revisions"}],"predecessor-version":[{"id":7757,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/4915\/revisions\/7757"}],"wp:attachment":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/media?parent=4915"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/categories?post=4915"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/tags?post=4915"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}