An update on the NuGet package submission process

If you’ve submitted a package to the NuGet feed, then you’re probably aware that our submission process is not as good as it could be.  Ok, this may be an understatement, so let’s go ahead and say it: it sucks!

With the current process, you have to clone a repository that has all the other packages, add your package files to it, and submit a pull request.  Let’s first outline why this process is bad.


What’s wrong with the current process

Putting binaries in a DVCS is evil: DVCS like Mercurial work great for source code, but are atrocious for binary files.  When you pull down the packages repository, you’re not just copying all the other packages’ binaries, but you’re copying down any binary that has ever existed in there.  So whenever something is deleted or moved, we’re forever paying the price for that old binary.  Bottom line: the repo has become very large, and cloning it is painful.

It takes longer to get your packages live: after you send a pull request, you have to wait until it is accepted before your package can go live on the feed.  This is frustrating, as you should be able to push packages nearly instantly.

It makes *my* life difficult: somehow, I’m the sucker on the NuGet team who signed up for taking care of pull requests.  While I got pretty good at it, it’s still time consuming given that rate at which they’ve been coming.  And yes, there are other things I’d prefer to do with my time! Smile


Though it does have a couple advantages

I get to catch some package errors: if I see something that doesn’t look right, I can reject the pull request and tell the author to fix things.  This results in a feed with less bad packages.  Though better tools will allow this to become unnecessary.

It allowed for global changes: since we have all the package pieces in one place, we were able to change everything at once when we made changes to the nuspec format, and this was very useful.  But once 1.0 goes out (soon!), we will keep the format backward compatible, so this won’t be necessary.


If the process is bad, why did we choose to use it?


We really wanted to get NuGet out there as early as possible, and we just didn’t have a gallery ready.  So we came up with this temporary process to get us going in the short term.  As it turned out, it has lasted longer than we were hoping.  Another factor is that you guys submitted way more packages than we were expecting.  Though don’t get me wrong, we are very happy about that part!

So this little system that we expected would be used for a month or two and handle 50ish packages ended up being used quite a bit longer than it should have been, and on a feed that now has 312 packages.


So when will get better?


The good news is that we’ve made some good progress on our gallery, and it will soon be ready to go public.  In fact, this gallery is being developed as open source, so there is absolutely nothing secret about it.  You can find the source at and (it has a gallery piece and a backend piece).

With this new system, submitting a package will be as simple as building the nupkg file (using NuGet.exe), and uploading it to the gallery.  It’s basically the same thing as uploading a VSIX to the Visual Studio extension gallery.  The package will be live on the feed instantly.  There is even a way to do this from the command line.

I don’t know exactly when this will go live, but it should be soon…


Now I’ll let you in on a little secret


The truth is that we are already using the new gallery!  Some of you may have noticed that the fwlink now redirects to, while a week ago it went to  And this new link is in fact running the new gallery’s backend code (note that the URL will likely change again).

Also, when you submit new packages, I’m now submitting them to the new gallery using the command line tool.  The part that’s not quite ready for prime time is the Orchard front end, which will let anyone create an account and submit packages.

But be patient, it’ll soon be ready!

Comments (0)