Selecting local NuGet server
Doesn’t matter if you are a big corporation, small company, a team of people or even a single person writing software it is worth organizing your code in modules and reuse it.
Using .NET (Standard/Core/Framework …) has the advantage of NuGet. It is open source package manager for .NET. You can use the public feed on https://www.nuget.org/, run your own NuGet server or create a local feed.
Let’s start with the simplest one – Local Feed.
Local NuGet package feed is just a hierarchical folder structure on your file system where packages are placed. It can be on the local machine or on the local network. This local feed or feeds can be used as package source as any other NuGet feed.
Note: Hierarchical folder structures are supported in NuGet 3.3+. Older versions use single folder.
I am not going to go into more details about local feed since I would like to have a nice GUI and file explorer is not exactly what I call a nice GUI for packages.
So let’s go and check what are the other options we have.
Quick search on internet shows that there are many available options:
- NuGet Gallery – Packages on nuget.org are hosted with this server.
- Artifactory from JFrog.
- Azure Artifacts, which is also available on Team Foundation Server 2017 and later.
- BaGet, an open-source implementation of NuGet V3 server built on ASP.NET Core
- Cloudsmith, a fully managed package management SaaS
- GitHub package registry
- LiGet, an open-source implementation of NuGet V2 server that runs on kestrel in docker
- Nexus from Sonatype.
- NuGet Server (Open Source), an open-source implementation similar to Inedo’s NuGet Server
- NuGet Server, a community project from Inedo
- ProGet from Inedo
- Sleet, an open-source NuGet V3 static feed generator
- TeamCity from JetBrains.
I am sure there are pros and cons for all of them.
As a beginning, one compare is – do we want to have a single server doing multiple things or we want server for each service – CICD, package manager, symbols server and so on. The plus to have one server is to utilize better the resources. It is also easier to maintain. And the minus is that if one server is down for some reason few services goes down at the same time. In a big company this might be a real issue but not for me (at least for now).
Then it is coming if you prefer Windows or Linux installation. Some of the servers support both. I don’t have strong preferences about that except for the price of Windows Server license (I will go with a trial).
Right now I am going to try two of them. ProGet – installed in a docker containers. TeamCity – installed in Windows Server VM.
Ubuntu Linux 18.04 LTS with docker containers.
Windows Server 2016 Standard.
Installation of the ProGet was much faster than TeamCity. I know it is not a big deal since you do it once, but it was noticeable. If we take into account that TeamCity is much more than just a NuGet package manager, then it is good.
Having both of them installed I spent a some time with them, so far I like better ProGet. It is more intuitive and has better control over the feeds.
TeamCity connect the feeds with a specific project you have created there. At least at this point I don’t want separate feed for each project.
Another advantage of ProGet is the ability to have different feed types – NuGet, npm, PyPI, PowerShell, Debian and so on. It can be useful if you use more than just NuGet in your projects.
After this short compare that I did I definitely like better ProGet and I am going to stick with it.
Here is how the WebUI in ProGet is showing the package.
While playing with the NuGet servers there was a new version of the ProGet, so I did try the update procedure. It was as simple of stopping the old server container, getting the new one and starting it. The database container stay the same.
This is what suit me but in no means this is something that will work for all. If you have any other experience and want to share different server you use and why you like it, please do in the comments.