4 August 2015 Comments Off on Using Nuget Packages for Centralized Code General Software Development
Author: David Hales
For about 4 years now, I have been utilizing Nuget Packages as a way to reuse centralized code.
What do I consider centralized code?
I’m going to go a bit more in depth into my DM.Core package, as it is the center of what I am describing of using a centralized or ‘Core’ code base.
I currently use my DM.Core as a place to store methods and functions that I want to and can use in any of my projects. Email settings, encryption settings, object extension methods, and various other things.
For example, my simple encryption handler has an Encrypt method, and a Decrypt method, which simply Encrypt and Decrypt a string using a base key. I have also created these as extension methods, so I can simply Encrypt and Decrypt a string like so:
Other examples I have are extension methods for object.ToBool, object.ToInt, object.IsNull, object.IsNotNull.
The extension methods are basically shortcuts to simplify code. For example, ToInt does an Int.TryParse and if it gets an Int, it returns that, if not it returns 0.
Object.IsNull is basically a shortcut of writing out object == null. Not a big thing, but a fun little shortcut. Other examples include string.ToFormattedPhone, which formats a string into a desired phone number format. Also, string.IsValidEmailAddress, which uses a regular expression to validate if the string is an email address format.
Methods like these can be used to simplify code in a lot of places, and would be tiresome to duplicate in more than one place. Usually these are kept in a single file inside a given project, so that that project can use them. What I do, is I have a separate project that I call DM.Core, and after compiling it, I package the dll into a Nuget Package.
So I’ll show you that now, which is really what this article is about.
Creating a package is easy. What you need to first, is decide where do you want your package to reside? There are a few options. You can host the file with nuget.org, which makes it available to the world. You can set-up a Nuget server inside your network that you can access using your local network, or you can set-up a nuget server that is accessible on the web. The last two options are essentially the same thing, the latter just requires you open the website up to be accessible through your firewall/DNS etc.
There are a lot of sites out there that cover how to set-up your own Nuget package feeds. No sense in me covering this. I used the following straight from nuget.org to set up mine: https://docs.nuget.org/create/hosting-your-own-nuget-feeds
So how do you create your own Nuget packages?
There is a great bit of software out there someone has written that makes this so simple.
Nuget Package Explorer
Note: If you set up a nuget feed that is secured and requires a password, the latest version of the Nuget Package Explorer does not work. You will need to download and run version 3.6 in order to be able to enter credentials to a secured Nuget feed. I learned this the hard way.
Open the Package Explorer:
Select Create New Package.
Click the Edit Metadata button
Fill out the details of the package. I version mine based off the date, example. If I built a new package on January 1st of 2015, my version becomes:
2015.0101.01 – This is 2015 January 1st version 01 for that day. Then if I need to make another version that day, I increment that end number by one. It becomes:
2015.0101.02 – This gives me an idea of when the package was last updated, etc. Just the way I like to do it, you can do it however you want. The key, is that you always need to increment the version up somehow, whenever you modify a package, or your applications don’t see it as a new version.
Once you have filled in your details as you want, click the check mark.
Next, you want to add the dll’s from your project that will be included in your package.
Select CONTENT -> Add -> Lib Folder
Next, you can right click on the Lib folder, and select Add Existing file, or you can drag and drop dll files to the folder as well. You want to make sure to put the files inside the Lib folder.
Select the dll files pertaining to your project you want included.
I always add the dll and the pdb file to my packages.
Next step depends on if you are using online feed or a local source. Local sources, you can save the file to the packages folder of your local nuget feed. If you do File -> Save As, it will default the file name to the ProjectName combined with the version, so that when it saves, the package will show as a newer version.
For an online feed, select Publish from the file menu
Enter your feed url and the publish key. You would have set this up when you set up the server.
Click publish, and the package will get published. Now you can add this location to your Nuget Package Source in Visual Studio. Then include the using at the top of the class you wish to use it in, and you are set.
To update a package, just open it from local, or online feed, and make your modifications to Metadata. (Remember to update the version), and add the new dll and pdb files, and re-save or publish the package.
This can be used for all sorts of applications. I use it as a way to populate my Entity Frameworks objects into various projects, so I can keep a centralized project that is outside of my Front End sites. It can be used anywhere you have reusable code that you could offload into a separate project and load into multiple projects using the Nuget packages.
Author: David Hales
Tags:
