MyGet Blog

Package management made easier!


MyGet Build Services - Public Beta

We’re happy to announce that MyGet Build Services is in Public Beta since, well, now. MyGet Build Services enable you to add packages to your feed by just giving us your Git, Mercurial or Subversion repo. We build it, we package it, we publish it. And starting today, every MyGet user can use it.

More information on MyGet Build Services can be found in a previous blog post, although some things have been updated. You’ve provided us feedback through our UserVoice, resulting in the following changes:

  • We now support .NET Framework 4.5. New features available in .NET Framework 4.5 are described at
  • Build hooks! The list of your build definitions now shows a build hook URL which you can link to your GitHub or BitBucket repository. Calling this build hook (HTTP POST) will trigger a new build. Or in other words: a commit will trigger a build.
  • Our build server now checks for a file called build.bat first, then MyGet.sln, then your .sln and then .csproj/.vbproj files (UV)
  • We now support Git, Mercurial and Subversion repositories (UV)
  • You’ll now have some tools available in the environment variables (UV)
  • There’s more information in the build logs (UV)

Keep the feedback coming! Build Services are now enabled on every MyGet account. Do note MyGet Build Services are still a beta, and as Willy Wonka would say… “Little surprises around every corner, but nothing dangerous.”

Happy packaging!

PS: Why not deploy your freshly built apps using Octopus Deploy?

MyGet Build Services - Join the private beta!

Good news! Over the past 4 weeks we’ve been sending out tweets about our secret project MyGet project “wonka”. Today is the day Wonka shows his great stuff to the world… In short: MyGet Build Services enable you to add packages to your feed by just giving us your GitHub repo. We build it, we package it, we publish it.

Our build server searches for a file called MyGet.sln and builds that. No problem if it's not there: we'll try and build other projects then. We'll run unit tests (NUnit, XUnit, MSTest and some more) and fail when those fail. We'll search for packages generated by your solution and if none are generated, we take a wild guess and create them for you.

To make it more visual, here are some screenshots. First, you have to add a build source, for example a GitHub repository (in fact, GitHub is all we currently support):

MyGet Add build source

After that, you simply click “Build”. A couple of seconds or minutes later, your fresh package is available on your feed:

MyGet build package

MyGet package result

If you want to see what happened, the build log is available for review as well:

MyGet build log

Enroll now!

Starting today, you can enroll for our private beta. You’ll get on a waiting list and as we improve build capacity, you will be granted access to the beta. If you’re in, tell us how it behaves. What works, what doesn’t, what would you like to see improved. Enroll for this private beta now via Limited seats!

Do note it’s still a beta, and as Willy Wonka would say… “Little surprises around every corner, but nothing dangerous.”

Happy packaging!

PS: Why not deploy your freshly built apps using Octopus Deploy?

Feature highlight: MyGet Gallery

It's been less than two months since we introduced the public MyGet Gallery, and we are very happy to have some awesome projects onboard, often shipping development builds or using MyGet as a staging environment before pushing packages upstream. These feeds deserve more attention and people should know these feeds exist.

Did you know you can get the latest development builds of SignalR and MVC Contrib delivered through MyGet?

If you think your project's development builds deserve a place in our Gallery, you can easily opt-in using your feed's Gallery Settings.

Gallery feed readme

Our latest v1.3 release now allows feed owners to add a feed readme for publication in the MyGet Gallery. This way, feed owners now can easily add some instructions or disclaimers to the gallery feed details page using the well-known markdown format. Don't forget to add a link to your project page and/or sources as well.

You might recognize the pagedown markdown editor there, which is also used on the StackExchange Web sites, so you are probably already familiar with it. In return for this excellent control, we also added the StackOverflow identity provider to our login page. People who prefer to login using their StackOverflow account can now do so, or you can link it to your other identities within your MyGet account as well.

Layout improvements

While at it and based on the invaluable feedback of our users, we also improved the look-n-feel of the packages and feed listings by removing clutter and putting focus on content.

You can now not only see which packages are listed, and what version they're at, but you can also track when this version has become available. A simple click on the icon next to the package will trigger a package download in your browser, whilst the icons on the top right bring you to the SymbolSource symbols repository of this feed (if available) or give access to the RSS feed associated with this package repository.

What's next?

The screenshot below (taken from our latest development builds) is giving you a glimpse at what's coming next: user profiles and activity streams! That's right: you'll be able to get insights into the activity of a public feed or track the history of a given package. Coming soon...

We hope you like it! Keep those suggestions and feedback coming! Who knows, maybe one day you'll see your wish granted :)

Happy packaging!

MyGet Update: version 1.3.0

We are happy to announce a new version of the MyGet Web site containing a set of improvements, fixes and updates.

The following work items have been addressed in this release:


  • number of plans has been reduced. We now have Free, Starter (formerly Small plan), Professional (formerly Large plan) and a new Enterprise plan
  • introduction of the new Enterprise plan focused on companies that require more performance, integration and security


  • improved layout and readability on smaller screen resolutions
  • auto-lower cased routing for feed URL (helps avoiding issues caused by incorrect casing of feed identifier)
  • upgraded to MVC4
  • new identity provider: StackExchange
  • upgraded SymbolSource integration to take benefit from their improved and freshly released API
  • Gallery feeds now support a README in Markdown format, available in the feed's Gallery Settings
  • Enterprise plan: upgraded administrative & quota management dashboard
More details about the new features will be covered in follow-up blog posts soon.
Happy packaging!

Manage NuGet Package Sources using PowerShell

If you regularly need to manage your NuGet package sources in Visual Studio, and got familiar to using the NuGet Package Manager Console for all kinds of operations and automation, you might find the following approach appealing.

This approach will save you a few clicks and is based on a very cool tools package called ManagePackageSource. This NuGet package installs a few extra PowerShell commands into your NuGet PowerShell profile. That’s right, NuGet supports its own PowerShell profile! So instead of installing these tools packages over and over again every single time you create a new solution, let’s simply install these commands once and for all, so they are always available.

To do so, simply run the following command:

Install-Package ManagePackageSource

You should see the following output in the NuGet Package Manager Console



After that, you can simply uninstall the package again from your project to undo the changes in your working directory. The commands have been installed into your NuGet PowerShell profile and the profile has been reloaded, so they will remain there even without ever needing to install this package again.

If you happened to have another instance of Visual Studio open before installing this package, you can reload the profile as well in this other instance by running the following command in the NuGet Package Manager Console:

. $profile

In case you’re wondering where we changed stuff on your computer, you can find the NuGet_powershell.ps1 profile in the C:\Users\username\My Documents\WindowsPowerShell\ directory, and the new ManagePackageSource module can be found under the Modules directory inside that one.

To register a new NuGet feed into your Visual Studio, for instance a MyGet feed, you can run the following command now:

Add-PackageSource "My MyGet feed" ""

If you're interested into the sources, you can obviously unzip the NuGet package or browse the code on our GitHub repository. Feel free to contribute your own extensions and improvements!

MyGet support for multiple logins (and GitHub)

Last week, we’ve deployed a major update for MyGet. Next to support for pushing packages to other feeds and the new MyGet Gallery, we’ve done some updates to our authentication mechanisms. From now on, you can link multiple social identities to your MyGet account. For example, I’ve linked Google, Facebook and Windows Live ID to my own account so I don’t have to think about which account I have to use to login.

MyGet GitHub SupportAs a bonus we now also support GitHub as an identity provider. This enables you to log in to your GitHub account and be logged in across all GitHub related websites using a single sign-on experience.

You can set up these multiple identities (and GitHub) on your profile page. Follow the Add identity provider hyperlink and complete the process.


Happy packaging!

Introducing MyGet Gallery

Included in our latest release of 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.


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.


Happy packaging!

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 (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 (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.


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!

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("")]
[assembly: AssemblyFileVersion("")]
[assembly: AssemblyInformationalVersion("")]

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, 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>.

Pro NuGet is finally there!

Short version: Install-Package ProNuget or

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