Introducing MyGet Gallery

Included in our latest release of www.myget.org last week, we’ve deployed the new MyGet gallery. We’ve noticed a lot of NuGet packages for popular open-source projects (such as Dotspatial or Mvccontrib) are hidden in their continuous integration feeds on MyGet. To make it easier to find these hidden treasures, we’ve released the MyGet Gallery.

The MyGet Gallery enables you to browse around through selected public feeds and browse packages listed on those feeds. It’s an initial release of this feature and we’re looking forward to hearing your comments through our UserVoice.

image

Get your feed listed, too!

You can opt-in to be listed in the MyGet Gallery too. Simply navigate to your feeds and edit the settings under the MyGet Gallery tab. You can select to be either listed or unlisted in the MyGet Gallery. It’s also possible to add a logo of choice.

image

Happy packaging!

Author: Maarten Balliauw on 06 Jun 2012

Pushing packages from MyGet to NuGet (or another feed)

Imagine you have a package repository hosted on MyGet. Every time a team member of your open source or enterprise project commits source code changes, your build server pushes an updated release to this package repository in the form of a prerelease NuGet package. Now what happens if a release to the official NuGet package source has to be created? Typically, you will either create a fresh package which will be the package to release, or download a package from your build server, change the version and upload that one to NuGet.org (or another repository). No need for such overloaded process anymore: MyGet will perform the push for you.

Setting up a continuous integration (CI) feed

First of all, you will need a CI feed to which your build server can push every NuGet package related to your project. Simply create your feed on MyGet, a three-second process. After creating your feed, MyGet will present you the feed URL as well as an API key. Optionally, you can make it a private feed and ensure only people who were granted the correct privileges can access your feed.

Next, configure your build server to push the NuGet artifacts to MyGet. Using TeamCity, for example, this can be done by adding a NuGet Push build step:

MyGet feed TeamCity

Pushing packages from MyGet to NuGet (or another feed)

The first time you want to push a package to another NuGet feed, you’ll probably have to configure the other feed’s URL and API key to use when pushing there. The push package feature is based on the package source proxy feature released earlier. Navigate to your feed and on the left hand side, click the “Package Sources” item and either add a new package source or edit the existing, default NuGet package source. In order to be able to push a package to another feed, the API key has to be specified. You can enter your NuGet.org (or another feed) API key and click the Save button.

MyGet package source selection

Pushing packages from MyGet to NuGet or any other feed is easy. From the moment a package source has been configured, using the “Push” button will enable you to push packages to another feed.

image

After clicking the “Push” button, MyGet will present you with an overview of the package which will be pushed to another feed. Select the feed to which you want to push and verify the other fields. When pushing a prerelease package to a stable package, simply make the Prerelease tag field blank. You can also modify the prerelease tag if wanted. If you do intend to push a prerelease version, simply continue clicking the “Push” button.

Push a NuGet package

Told you it was easy. MyGet will now push the package to the selected feed and inform you by e-mail should anything go wrong. Happy packaging!

Author: Maarten Balliauw on 06 Jun 2012

NuGet $version$ token explained

Many questions that often come to mind when building NuGet packages are related to versioning. There's one question in particular I'd like to post here because it's one of the easier to answer. The question is: How do I use the $version$ token in the NuGet manifest (nuspec) file? Where does it get the version number from?

If you look at the NuGet docs explaining the nuspec replacement tokens, it states that the following - if it doesn't, my pull request got accepted :) - The assembly version as specified by the assembly's AssemblyVersionAttribute.

That is not entirely accurate (got a pull request accepted on the docs, so this should be fixed soonish). Consider the following AssemblyInfo.cs file contents for example.

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyInformationalVersion("1.0.2.0")]

This is where most people get confused. I won’t get into the details of which version attribute you should or should not use, as there can be good reasons to use either one of them in different scenarios. I’ll focus on how nuget is using this information to provide a version number to the $version$ replacement token in the nuspec file.

Building a NuGet package using a tokenized nuspec file that relies on assembly information can be achieved in various ways, for instance:

  1. nuget spec <csproj> to generate the tokenized nuspec, followed by nuget pack <csproj>
  2. nuget spec –a <assemblyPath> inside the csproj folder to generate a non-tokenized nuspec (so with the metadata already filled in), followed by nuget pack <nuspec>

Basically, it comes down to this:

  • If the AssemblyInformationalVersion attribute is available, then that one is used.
  • If the AssemblyInformationalVersion attribute is not available, then the AssemblyVersion attribute is used.
  • If none of the above are specified, your assembly will have a version number of 0.0.0.0, as well as the resulting package.
  • NuGet totally ignores the AssemblyFileVersion attribute.

Note that this behavior is the same when skipping the nuspec at all and building a nuget package directly from an assembly, using using nuget pack <assembly.dll>.

Author: Maarten Balliauw on 27 Apr 2012

Pro NuGet is finally there!

Short version: Install-Package ProNuget or http://amzn.to/pronuget

Pro NuGet - Continuous integration Package RestoreIt’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
  • More!

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 ;-)

Author: Maarten Balliauw on 12 Mar 2012

How to help yourself when NuGet goes down

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.

pinksombrero

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:

%Localappdata%\NuGet\Cache

Avoid spending your day fingers crossed!

Author: Maarten Balliauw on 09 Mar 2012

Where MyGet is going

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.

More features

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!

Introducing subscriptions

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 info@myget.org! 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.

Happy packaging!

Maarten & Xavier
The MyGet Team

Author: Maarten Balliauw on 01 Mar 2012

Introducing MyGet package source proxy (beta)

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:

MyGet Feed Proxy Aggregate Feed Connector

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:

MyGet hosted package source

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:

Add package source proxy

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.

Conclusion

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!

Author: Maarten Balliauw on 01 Mar 2012