You probably know NuGet (and if you don’t, just click that link). And, if you write a lot of the same types of projects, you probably have a few libraries you reuse in those projects. Wouldn’t it be nice if you could install those libraries just as you install JQuery, Entity Framework or ‘your favorite package here’, but just not share that package with the entire world.

As always, there are plenty of ways to achieve this. Each has its pros and cons, and I decided to do a write-up of what is possible. So, first the options:

• Simple file share containing packages
• Automatically synchronized (cloud) file share containing packages
• Internal nuget server
• NaaS – NuGet as a Service

So now that we have the options, lets see what they are all about.

Simple file share containing packages

When you open the NuGet settings you will be able to add your own package source. This does not have to be a URL per se, but can also be a file location on a network drive or your own machine:

Pros:

• Easiest to setup.
• When using a file share on a network drive, accessible for all users inside your network.

Cons:

• Not easily available outside your company network.

Automatically synchronized (cloud) file share containing packages

The same as above, but now you use Skydrive, Dropbox, or any other cloud storage provider to synchronize that folder in the cloud for easy access when working from home or plane.

Pros:

• Still easy to set up (on your clients at least).
• Package source always with you, and automatically syncs when you are online.

Cons:

• Setting up access rights to more people than a small team (4 or 5 people) is going to be a maintenance nightmare.
• Try explaining a Dropbox or Skydrive installation on your build server to Corporate IT.

Internal NuGet server

In this scenario you setup your own NuGet server, which will probably consist of a website and some web services hosted on IIS (I am not sure if there are any non .NET NuGet servers out there). There are a few options with a varying degree of features and installation effort needed.

• NuGet.Server – Quiet easy to install (will probably explain in a future post) if you know a bit of IIS, but limited functionality.
• Official NuGet Gallery Website and Services – A bit harder to install, you also need a SQL database.

Pros:

• Once installed, easy to expose to outside the local network so you can access it from anywhere.
• Works just like the official NuGet Package Source, which means that you don’t need separate build scripts for packages you want to push to the official source and the internal source.
• Easily incorporated in automatic build scenarios.

Cons:

• Hard(er) to set up.

NuGet as a Service

I recently found MyGet, which hosts NuGet feeds. The idea is quite simple you register with them, a feed is created for you, and you can contribute to this feed. They have 4 different plans of which only 1 is free. More details on those plans here.

Pros:

• Easy to set up.
• The enterprise plan has a lot of nice options.
• Easily incorporated in automatic build scenarios.
• Available wherever you have an internet connection.

Cons:

• Advanced and user/quota management features come at a price.

Conclusion

As you can see, there are plenty of options to create your own NuGet feed. I have chosen to install my own NuGet server (because I only found out about MyGet after I finished, and I love to get my hands dirty with that kind of stuff). So I’ll probably write a tutorial on that one some day.

If you need/want a private NuGet package feed is totally up to you. But if you do, there are plenty of options to get you started. And I hope this post has helped you make a decision.