Short version: Install-Package ProNuget or http://amzn.to/pronuget
It’s been a while since I wrote my first book. After I’ve been telling that writing a book is horrendous (try writing a chapter per week after your office hours…) and that I would never write on again, my partner-in-crime Xavier Decoster and I had the same idea at the same time: what about a book on NuGet? So here it is: Pro NuGet is fresh off the presses (or on Kindle).
Special thanks go out to Scott Hanselman and Phil Haack for writing our foreword. Also big kudos to all who’ve helped us out now and then and did some small reviews. Yes Rob, Paul, David, Phil, Hadi: that’s you guys.
Why a book on NuGet?
Why not? At the time we decided we would start writing a book (september 2011), NuGet was out there for a while already. Yet, most users then (and still today) were using NuGet only as a means of installing packages, some creating packages. But NuGet is much more! And that’s what we wanted to write about. We did not want to create a reference guide on what NuGet command were available. We wanted to focus on best practices we’ve learned over the past few months using NuGet.
Some scenarios covered in our book:
- What’s the big picture on package management?
- Flashback last week: NuGet.org was down. How do you keep your team working if you depend on that external resource?
- Is it a good idea to auto-update NuGet packages in a continous integration process?
- Use the PowerShell console in VS2010/11. How do I write my own NuGet PowerShell Cmdlets? What can I do in there?
- Why would you host your own NuGet repository?
- Using NuGet for continuous delivery
I feel we’ve managed to cover a lot of concepts that go beyond “how to use NuGet vX” and instead have given as much guidance as possible. Questions, suggestions, remarks, … are all welcome. And a click on “Add to cart” is also a good idea ;-)
Let the world know its current situation!
Today will be remembered as the day that NuGet.org went down and broke quite some builds. While many people would love to see the NuGet team wearing a pink sombrero, there is something to say about wearing it yourself if you did not manage to workaround this. Let me explain…
First of all, just as with the Azure downtime on a leap day, whenever you rely on an external system and make it mission critical, you should design for failure. You need to anticipate downtime. I’m sure the NuGet team does everything within its power to fix this and is going to inform us whenever they can, but give them some credit please: we’re all human beings making mistakes, that’s how we learn.
How do I know it’s not just me?
Here’s what you can do
The best thing one can and should do, again, is to anticipate. Have a backup repository, or mirror packages on a MyGet.org feed. Looking at my twitter streams, it is striking to see how many did not think about it.
If you have your packages in source control, impact is limited to not being able to upgrade your packages or install new packages. If you don’t have your packages in your VCS, and you did not anticipate, you might get lucky enough and fix your builds by targeting the local NuGet cache.
Simply register the following path as a NuGet package source and target this one:
Avoid spending your day fingers crossed!
Time flies. MyGet has been online for over half a year! We’ve started MyGet as a proof-of-concept which kept growing, thanks to you. You’re one of the more than 600 NuGet feeds we are currently hosting in two datacenters worldwide!
New user interface design, new blog
We’ve “moved your cheese around”. We’ve been redesigning our UI and added a few usability improvements here and there.
Next to that, our new blog went live at blog.myget.org. We will be using it to announce new features, provide sample use cases for MyGet and share other information with you.
It have been a couple of busy weeks. The new release of MyGet which we've just deployed contains an important number of new features. Some small ones, such as the ability to delete all non-latest packages from a feed at once.
We've also added an often requested one: the ability to include packages in your MyGet feed from a different source such as Chocolatey or Orchard Gallery. Xavier blogged about this in MyGet tops Vanilla NuGet feeds with a Chocolatey flavor.
Building on that feature, you can link another feed and include a complete or filtered set of packages from that feed. This offers the ability to have one single package source endpoint which aggregates different external feeds and is enriched with your privately hosted packages. Maarten blogged about the why and how in his post on MyGet package source proxy (beta).
Let us know about your experiences with these new features. You posted these features on our UserVoice feedback forum, we are looking forward to hearing more at UserVoice!
Since we want to build much more features and improvements, we're looking for some funding to buy ourselves time to do that. We’re introducing subscriptions: a free plan, which still allows you to do what you’ve been doing today. Our small, medium and large plans offer some additional capabilities to your feed. No worries! We’ve promised you to host your feeds and we’ll keep doing that.
Checkout the available plans at www.myget.org/plans and discover which plan we've assigned to you for two months as a gift to say thank you for using MyGet.
It's your product
Know that you can reach out to us through UserVoice or email@example.com! Let us know your thoughts, feature requests or anything else you would like to share! MyGet is your product, and we want to make sure it stays that way. We’re just the code monkeys making sure you can host your packages and dependencies in a reliable and useful way.
Maarten & Xavier
The MyGet Team
My blog already has quite the number of blog posts around MyGet, our NuGet-as-a-Service solution which my colleague Xavier and I are running. There are a lot of reasons to host your own personal NuGet feed (such as protecting your intellectual property or only adding approved packages to the feed, but there’s many more as you can <plug>read in our book</plug>). We’ve added support for another scenario: MyGet now supports proxying remote feeds.
Up until now, MyGet required you to upload your own NuGet packages and to include packages from the NuGet feed. The problem with this is that you either required your team to register multiple NuGet feeds in Visual Studio (which still is a good option) or to register just your MyGet feed and add all packages your team is using to it. Which, again, is also a good option.
With our package source proxy in place, we now provide a third option: MyGet can proxy upstream NuGet feeds. Let’s start with a quick diagram and afterwards walk you through a scenario elaborating on this:
You are seeing this correctly: you can now register just your MyGet feed in Visual Studio and we’ll add upstream packages to your feed automatically, optionally filtered as well.
Enabling MyGet package source proxy
Enabling the MyGet package source proxy is very straightforward. Navigate to your feed of choice (or create a new one) and click the Package Sources item. This will present you with a screen similar to this:
From there, you can add external (or MyGet) feeds to your personal feed and add packages directly from them using the Add package dialog. More on that in Xavier’s blog post. What’s more: with the tick of a checkbox, these external feeds can also be aggregated with your feed in Visual Studio’s search results. Here’s the magical add dialog and the proxy checkbox:
As you may see, we also offer the option to filter upstream packages. For example, the filter string substringof('wp7', Tags) eq true that we used will filter all upstream packages where the tags contain “wp7”.
What will Visual Studio display us? Well, just the Windows Phone 7 packages from NuGet, served through our single-endpoint MyGet feed.
Instead of working with a number of NuGet feeds, your development team will just work with one feed that is aggregating packages from both MyGet and other package sources out there (NuGet, Orchard Gallery, Chocolatey, …). This centralizes managing external packages and makes it easier for your team members to find the packages they can use in your projects.
Do let us know what you think of this feature! Our UserVoice is there for you, and in fact, that’s where we got the idea for this feature from in the first place. Your voice is heard!
We recently deployed an all new version of MyGet.org, which contains quite a lot of optimizations and some new features as well. If you didn’t notice, go check it out!
My personal favorite is in fact the underlying architecture that allows us to aggregate feeds and link package sources. These package source presets are configurable on Feed level through the new Package Sources tab available in the Feed management interface.
To add a package from these package source onto your own feed (either referenced or mirrored, with or without its dependencies), navigate to the Add Package dialog and select the From Feed tab (previously called ‘From NuGet.org’).
The default setting is still NuGet.org obviously, but you might notice the dropdown containing another feed: Chocolatey.org! That’s right, why not add Chocolatey to your package sources and build a feed containing your favorite tools?
Build your own favorite Chocolatey tools feed
Building such feed is very straightforward. Choose a feed name (which will be represented in your URL) and provide a meaningful description.
All that is left for a basic MyGet feed is to choose one of the predefined feed templates, as shown below. Obviously you can modify and tweak these settings further to meet your needs afterwards. We’ve updated our FAQ with a full explanation of MyGet’s security model and how you can assign or revoke user rights on a feed.
Once the feed is created, you can start pushing packages to it. We support various ways of doing so, including:
- Uploading packages through the website (and optionally mirror any dependencies found on the configured package source)
- Referencing or mirroring packages from another feed (any package source, such as NuGet.org, Chocolatey.org, …)
- Uploading a packages.config file, targeting any package source
Let’s add some packages from the Chocolatey Gallery shall we? Simply select the Chocolatey Gallery package source and type any package name (or any other search criteria using our other search options). Autocomplete will kick in after you typed a character or two and show you a list of possible matches. Select the one you want, verify whether you want to only reference it (copy the metadata onto your feed and keep the real package in the package source) or mirror it (deep copy). If you perform a deep copy, you might prefer to opt-in and check the include dependencies checkbox.
After clicking the upload button, the operation is queued into the background for processing. It might take up to a minute until the package (and its dependencies if requested) appear on your feed. Note that we also cache the packages list on the website, but nevertheless, once processed they will appear instantly onto your feed when queried from within Visual Studio for instance.
For this demo, I only added GitExtensions to the feed but I mirrored it and included dependencies. After processing, my feed packages list contains the following packages.
Now it’s a piece of cake to add those other tools I’m using. You might be wondering…
Why do you want to do that?
Very simple: I don’t want to mess around with a script or packages.config file on multiple computers. If I repaved my system, that file is not on there. If I want to put it on that repaved machine, I need to find it back (that’s usually the real issue). And if I somehow manage to do so, it’s usually out-of-date.
What if there was a central (read: cloudy) location where I could keep track of this list? A single place to manage the tools list, and always the same location to refer to. Something that would reduce the installation of all my favorite tools to a one-liner. When drafting the Chocolatey chapter in our Pro NuGet book, I learned about the convenient –all command line option support by many of Chocolatey’s commands, including the update (cup) and list (clist) commands . That’s when it struck me that this switch was missing for the install (cinst) command, so I bothered Rob Reynolds (@ferventcoder) with it :) Rob was so nice to help us out and made sure the cinst –all –source [feedUrl] scenario would be supported in the near future. Guess what, it is! Thanks again Rob!
Knowing this, it’s pretty straightforward to repave a system and get all your favorite tools installed in no time. It suffices to run the following command (replace my feed with your feed):
cinst -all -source http://www.myget.org/F/myfavoritetools
Not only can you use it after repaving your system, you could use it as well every time you work for a new customer and need to set up your development environment (maybe have multiple feeds for various scenarios?), or why not share the feed with your team members and make sure everyone benefits from these awesome tools out there.
If ever you have a question about MyGet or need further assistance to get you started, please refer to our blog, reach out on twitter (@MyGetTeam) or use the Support form to contact us. We’ll be happy to help!