MyGet Blog

Package management made easier!


Preview support for the NuGet V3 protocol

A few weeks back, NuGet 3.0 was released. It’s a redesign of the NuGet client targeted at Visual Studio 2015, with a number of improvements and changes from earlier versions of NuGet. One of the changes the NuGet team made was on the server side, with a new protocol. We’re happy to announce that MyGet now has preview support for this new protocol as well!

The new NuGet server-side API was first written about in April 2014. And even before that, there was a talk Evolution of NuGet at MonkeySpace 2013. In it, the NuGet team describes what the NuGet team envisioned: a faster and more reliable API for .NET developers to consume packages. When opening the NuGet Package Manager Dialog in Visual Studio 2015 this becomes very visible: the well-known OData V2 feeds feel slow. MyGet now supports the NuGet V3 protocol (in preview), sharing the vision the NuGet team laid out over 2 years ago and made happen a few weeks ago: make NuGet package management faster.

Note: make sure to read the entire blog post when using private feeds - the NuGet client that ships with Visual Studio 2015 NuGet only supports pre-authenticated V3 feeds. An update is available with full private feed support.

How to make use of the NuGet V3 protocol with MyGet?

The URL of a MyGet feed typically looks like this: For the V3 protocol, this URL becomes This feed can be registered in Visual Studio 2015. From the Tools | NuGet Package Manager | Package Manager Settings menu, we can select the Package Sources tab and add a V3 feed in the same way as a V2 feed can be added. We can give the feed a descriptive name, and enter its URL.

Registering MyGet V3 API NuGet

Once added, we can manage packages for our project or solution, and select the newly added feed from the dropdown.

MyGet feed with NuGet V3 API protocol

Does this also work with private (authenticated) feeds?

It’s perfectly possible to consume private (authenticated) feeds on MyGet using the new NuGet client in Visual Studio 2015. Unfortunately there is a bug in the client that makes this a little hard: if it has to prompt for credentials, consuming the feed will fail. The NuGet team confirmed a fix is ready to be released (in fact, an RC version is out), but in the meanwhile a pre-authenticated feed URL can be used to consume a private V3 feed.

A pre-authenticated feed comes in the following format:, where the feedname is of course the name of the feed, and accesstoken is one of the access tokens that can be managed via the MyGet website.

Can upstream feeds be proxied?

The MyGet V3 feeds support proxying upstream V2 feeds (not V3 yet). This allows for registering one V3 feed URL in Visual Studio while proxying one or more external (V2) feeds over the same URL. This greatly speeds up working with NuGet! Have a look at our documentation to learn more about feed proxying.

When browsing MyGet, you may notice the V3 feed URL is not being advertised anywhere. The reason for that is twofold: we’re offering the V3 protocol as a preview. We want to make sure the feed behaves the way it should. Second, we want to continue improving V3 protocol support, for example by enhancing support for proxying upstream feeds with upstream V3 sources.

We would love to hear your feedback via @MyGetTeam or through the comments below.

Happy packaging!

Limited preview - VSIX support

MyGet has a rich feature set for NuGet, and we just recently added support for Bower and NPM registries. Now we'd like to give our users the opportunity to bring those rich MyGet features to VSIX as well!

What VSIX support will you get in this preview?

We currently have the full feature set we already have for NuGet, Bower and NPM. You'll be able to manage extensions, add them from upstream feeds (ATOM only), granular permissions and user management, support for community feeds... If you need a staging feed or just a private VSIX gallery, this is the easiest way to get one. Using the VSO integration? We'll pick up the VSIX artifacts from your VSO build and automatically add them to your MyGet VSIX feed.

I want to join the preview!

If you are interested in joining the private preview and eager to provide some early feedback, then just ping us with your username and we'll flip the feature toggle for your account.

MyGet 2.0 Release Notes

MyGet 2.0 was released on March 12, 2015.


This 2.0 release of MyGet adds brand new functionality to the service. With this release, we bring all the functionality we already had for NuGet also to Bower and NPM!

This means, from now on, you can use MyGet to host and build your own NuGet, NPM or Bower feeds, whether public or secured.


MyGet (all plans)

The following applies to all MyGet plans:

MyGet (paid plans)

Obviously all paid plans also get the enhancements made available on the free plan. The following applies to the MyGet Starter and Professional plans:

MyGet Enterprise

The enterprise plan has all functionality from the paid subscription plans, and more! The following applies only to the MyGet Enterprise plan:

MyGet Build Services

Bug Fixes

  • Improved detection of hanging builds
  • Build now properly fails when compilation fails and no packages have been produced or pushed to your feed
  • Upstream package source proxying enhancements
  • No longer prompt the user that a package update is available upstream if the package source is set to auto-update

Keep that feedback coming! MyGet is built for you!

Happy packaging!

Modify NuGet package description and release notes before pushing upstream

Ever enjoyed watching your builds go green to find out that the packages created had a typo in the description? Or you simply forgot to add release notes? Very annoying if you simply want to push your packages out there!

This annoyance triggered one of our dear customers to send us a feature request: "What if I could modify these fields before I hit the Push button?" Well, we thought that was indeed a great idea, so we implemented it, whilst we also gave the UI a little more love :-)

If you click the Edit button next to each package, you'll now have the ability to modify the pre-release tag, the package description, and the package release notes. With a click of a button, you can also apply the release notes to all packages listed in the dialog. 

And to finish it off, we support markdown in the release notes. Packages that have release notes which contain markdown will be rendered nicely on the package details page.

Happy Packaging!

IP whitelisting for MyGet Enterprise customers

Many enterprises access the Internet using one or more static IP addresses and prefer limiting access to their applications to those IP addresses. Good news: MyGet Enterprise customers can now whitelist IP addresses (or IP ranges) so only clients can only access MyGet if they are coming from the configured address. The whitelist will be applied for accessing the website, as well as for consuming hosted NuGet feeds.

IP whitelisting for MyGet Enterprise customers

Enterprise administrators can navigate to the administration dashboard, and create an IP whitelist under the Accounts tab. IP addresses can be entered on separate lines. If an entire subnet has to have access, the IP address can be suffixed with a CIDR suffix (e.g. /24) or a subnet mask (e.g. /

Happy packaging!

Build Services - Introducing pre- and post-build steps

With our 1.9.5 release out of the door, we’ve introduced support for pre- and post-build steps in MyGet Build Services. When using batch / PowerShell based builds for building your GitHub, BitBucket or Visual Studio Online projects and making NuGet packages for them, MyGet Build Services will scan for batch files to be executed. In addition to the default build.bat (or .cmd or .ps1), we search for pre- and post-build steps as well. These can be batch scripts or PowerShell scripts that are run before and after the actual build file.

When using MyGet Service Messages in the build, pre- and post-build steps can be used to prepare the build environment by setting the correct package version number, or creating additional environment variables for use by the build script.

More information can be found in our docs.

Happy packaging!

Build Services supports Service Messages

Service messages for MyGetWe’ve just deployed support for service messages in MyGet Build Services. With them, you can interact with our build agent by simply writing a message to the build output. This makes it easy to work with them from any build framework used, be it a simple batch file, PSAKE, MSBuild or others.

But what can you do with them? Why are they useful? There are a couple of situations that come to mind:

A service message looks like this: ##myget[buildNumber '1.0.0-beta1']. We also support a subset of TeamCity service messages. This makes your builds more portable between build systems and gives you more control of the build process. More information is available from our documentation.

Happy building, and happy packaging!

Web hooks released - Integrate MyGet with other services

A few weeks back, we announced the preview of MyGet web hooks. Today, we’re happy to say we’ve released web hooks for all our users. With web hooks, your feeds can communicate with external services whenever a specific action occurs on the feed. Events can be posted to your web server, e-mail, Twilio, Twitter, Visual Studio Online Team Rooms, HipChat and Slack.

Web hook types

Webhooks can be used to perform actions based on an event, for example sending out a tweet when a package is pushed or updating an issue tracker when a build succeeds. We’ve blogged some demos, for example on how to strong-name sign packages when added to a feed and how to implement custom retention policies. It’s not always required to write custom code though: we integrate with a variety of services such as Twitter, Twilio, HipChat and starting today, with Visual Studio Online Team Rooms and Slack.

Slack integration with MyGet

Only feed owners and co-owners can manage webhooks for a feed. Each webhook can be triggered for one or more event types, depending on the implementation. Webhook deliveries can be inspected, including full logs, as well as redelivered in case this is needed. Give web hooks a go!

Happy packaging!

MyGet 1.9.5 Release Notes

MyGet 1.9.5 was released on November 18, 2014.

Major Features

It's been a while since we tagged another MyGet release, but here we are, 9 months after tagging v1.9.0. We constantly ship and deploy improvements to our service so this v1.9.5 basically aggregates everything we've done since then, combined into a single milestone. This release contains many exciting new features. We'd love to hear from you so please send us your feedback


MyGet Enterprise

MyGet Build Services

Minor Tweaks and Bug Fixes

  • Build Services: Builds now fail immediately for feeds that return a 4XX or 5XX status code
  • Build Services: No longer ignore *Test*.nuspec files when packaging
  • Build Services: Assembly Version Patching no longer fails to process files that contain Visual Studio regions
  • Build Services: Delete web hook at GitHub / VSO when build source is deleted
  • API: nuget delete is no longer case-sensitive on package ID
  • Cloning gallery feeds now unpublishes the cloned feed from the gallery
  • Allow updating the description of access tokens
  • Support page - Ability to select the (own) feed related to the support request, which helps us provide even faster support! ;)

In addition, this release also contains a lot of performance fixes, and we continue to work hard on improving your overall MyGet experience. If you feel strong about a missing feature or have an idea for further improvement, please let us know! We build this for you!

Happy packaging!

Implementing custom package retention using webhooks

Earlier this week, we got the question if custom retention policies could be enforced on MyGet. More specific, the request was to be able to keep the latest 5 versions of a minor version (e.g. keep 1.0.6 through 1.0.2, but delete 1.0.1 and 1.0.0). We’ve introduced webhooks on MyGet to enable exactly this sort of scenarios!

Our own retention policies run whenever a package is added to a feed, so let’s see if we can implement a webhook handler that does exactly what was asked… The code for this blog post can be found in our GitHub organization.

Building the webhook handler

We’ll first need something that can run our custom logic whenever a webhook event is raised. This can be an ASP.NET MVC, Web API, NancyFx or even a PHP application. In this case, let’s go with an ASP.NET Web API controller. We want to be triggered on POST when a package added event is raised.

// POST /api/retention public async Task<HttpResponseMessage> Post([FromBody]WebHookEvent payload) { // The logic in this method will do the following: // 1) Find all packages with the same identifier as the package that was added to the originating feed // 2) Enforce the following policy: only the 5 latest (stable) packages matching the same minor version may remain on the feed. Others should be removed. string feedUrl = payload.Payload.FeedUrl; // Note: the following modifies NuGet's client so that we authenticate every request using the API key. // If credentials (e.g. username/password) are preferred, set the NuGet.HttpClient.DefaultCredentialProvider instead. PackageRepositoryFactory.Default.HttpClientFactory = uri => { var client = new NuGet.HttpClient(uri); client.SendingRequest += (sender, args) => { args.Request.Headers.Add("X-NuGet-ApiKey", ConfigurationManager.AppSettings["Retention:NuGetFeedApiKey"]); }; return client; }; // Prepare HttpClient (non-NuGet) var httpClient = new HttpClient(); httpClient.DefaultRequestHeaders.Add("X-NuGet-ApiKey", ConfigurationManager.AppSettings["Retention:NuGetFeedApiKey"]); // Fetch packages and group them (note: only doing this for stable packages, ignoring prerelease) var packageRepository = PackageRepositoryFactory.Default.CreateRepository(feedUrl); var packages = packageRepository.GetPackages().Where(p => p.Id == payload.Payload.PackageIdentifier).ToList(); foreach (var packageGroup in packages.Where(p => p.IsReleaseVersion()) .GroupBy(p => p.Version.Version.Major + "." + p.Version.Version.Minor)) { foreach (var package in packageGroup.OrderByDescending(p => p.Version).Skip(5)) { await httpClient.DeleteAsync(string.Format("{0}api/v2/package/{1}/{2}?hardDelete=true", feedUrl, package.Id, package.Version)); } } return new HttpResponseMessage(HttpStatusCode.OK) { ReasonPhrase = "Custom retention policy applied." }; }

Once we have this in place and are hosting it somewhere, we can configure the webhook on our MyGet feed.

Configuring the webhook

On our MyGet feed, we can create a new webhook. It should send application/json for the package added event to the URL where we deployed the above code.

Configure web hook

When this hook now triggers, we will be retaining just the 5 latest minor versions of a package (ignoring prereleases).

That’s it. Using nothing but webhooks, we can run our own retention policies (or other logic) when something happens on our feed (like strong-name signing packages, for example). There are a number of events that we can subscribe to!

Happy packaging!