Creating Your Own NuGet Packages
Creating Your Own NuGet Packages
Learn how you can reuse your code in multiple projects with NuGet packages, with an option to update whenever you push code.
Join the DZone community and get the full member experience.Join For Free
For a while, I have found myself writing the same bits of code for different web projects. This annoys me as it goes against the DRY principle (don’t repeat yourself).
One possible solution is to write your own NuGet packages. You can then add this piece of code to any project you work on.
nuget.org is the public NuGet feed where any developer can download NuGet packages. You could publish your NuGet package here, but your might want to restrict access so better to create a private NuGet feed.
Let's look at how we create a NuGet feed in Visual Studio. The first thing you need to do is install the Package Management extension to Visual Studio Team Services (it's free for fewer than 5 users), this will add a packages section under the build menu.
Before you can start using this new feature, you need to add a Package Management License in the users' hub.
Once that is done, you can create a feed. You need to give your feed a name and decide if only members of the current project or everyone in your account should have access to, read, and contribute to.
Now that you have a feed, you could use the NuGet package command to create a nupkg file and then NuGet push command to add it to your feed. A better way is to get Visual Studio Team Services to do all the hard work.
Create a new project in Visual Studio Team Service to house your NuGet package. In the build section, add an empty build definition. Choose a build agent, I am using the Hosted VS2017. Then add the following steps NuGet restore, Visual Studio Build, NuGet pack and NuGet push.
- NuGet restore – this step is only needed if your code depends on other packages. If it depends on other packages that are only in your feed you must specify your feed in the feeds and authentication section.
- Visual Studio Build – this builds your code like you would in Visual Studio. The only config I made to this step was to specify Release in configuration.
- NuGet pack – this creates the nupkg file from your built project. In configuration to package, specify the same as you specified in the previous step (in my case, Release).
- NuGet push – this publishes to your feed, so of course you need to specify your feed.
One last thing to configure is to enable the continuous integration option in triggers. This means whenever you push code, all these steps will run and you have a new version of your NuGet package.
In Visual Studio you need to create a *.nuspec file, this contains all the meta data about your NuGet package. Let's look at an example.
<?xml version="1.0"?> <package > <metadata> <id>$id$</id> <version>1.0.2</version> <title>Nuget</title> <authors>Simon Foster</authors> <owners>Simon Foster</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>An example of a nuget package.</description> <releaseNotes>Release Notes</releaseNotes> <copyright>Copyright 2017</copyright> <projectUrl>https://[yourVSaccount].visualstudio.com/nuget/</projectUrl> </metadata> </package>
One last thing to mention is version numbers. You can either change the version number in your *.nuspec file
You can use the automatic version number setting in the NuGet pack build step. However, I have found this only ever creates pre-release packages and I haven’t found a way to upgrade a package from pre-release to stable.
This is a really neat way to reuse your code in multiple projects. I have only been looking at this for a few days and I have already extracted code to do with emails, creating excel downloads, and database related methods. I suspect that doing this will also have a side benefit of forcing me to create code with fewer dependencies so more code can be turned into a NuGet package.
Published at DZone with permission of Simon Foster , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.