Some time ago I wrote about how you could create your own local (private) NuGet server by simply putting your .nupkg files out on a server share to which you had access. But there’s a better way still!
As more than one of my readers commented, this isn’t optimal as not only does a proper NuGet server serve up packages, it also has indexing and searching optimizations to help it perform more efficiently when you’re looking for and pulling down packages from within Visual Studio.
With that in mind, I set out to see how easy it would be to create a NuGet server for myself in Azure.
The meat to doing this is pretty straightforward and present in the NuGet documentation. The interesting part is doing it in Azure, which is just a hop, skip, and a jump once you’ve got the site all set up in Visual Studio.
Come back when you’ve followed all those instructions.
Welcome back!
Now that you have your NuGet website set up within VS, it’s time to push it to Azure. It really is amazing what they’ve done within VS to make this as painless as possible. I was pretty dumbfounded at first.
Right click your Web Application project and click “Publish…”
Next, choose “Microsoft Azure Websites”
Sign in to your Azure account, and then click New…
Pick something (available) for your site name and choose the Azure Subscription to which to tie it. You don’t need a database, so leave that as “No database”
Click ‘Create’ and VS will talk to Azure and create the website for you, right on the spot.
Once that’s done you’ll move to the next step in the wizard, with everything pre-filled for you (how nice!)
From here you can hit ‘Publish’ and up it goes!
As an added bonus, since Azure Websites gives everybody SSL certs, you get https access to your server as well.
And that’s IT. You have a fully-functional NuGet server that you can push to, pull from, and utilize in your build processes. If you’ve set an API key on it, then only those who know the key can push to it. If you want, you can lock down access to be able to pull using any of the myriad IIS Web Site security methods by simply editing the web.config that’s in the site and re-publishing it. For instance, at my workplace we have done this and set the web.config to allow only IP addresses belonging to the public block assigned to our network. It’s secure enough.
The best part? Run this process again with a different website name and you’ve got a chocolatey server as well!