MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

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

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!

MyGet supports Chocolatey

Chocolatey is something you need if you've ever installed, upgraded, or removed software on Windows. It is an existing, proven, almost 4 year old project. For those familiar with *nix package managers, it is a binary package manager, sort of like yum or apt-get, but for Windows. 

Here's how the team describes the tool on their Kickstarter campaign:

Chocolatey is a tool that automates all the mundane getting and installing software work for you. You just select what you want installed and within a few minutes, Chocolatey has downloaded and installed (or upgraded) that software without need for further input from you. So while Chocolatey does the hard work, you can go get some coffee. Or sleep. Or do other more important things. 

You probably start to see why we like Chocolatey!

Chocolatey has been part of the NuGet ecosystem since forever, and we are happy Chocolatey users ourselves. From the very first beta of MyGet's package sources functionality, we have had built-in support for ChocolateyIn fact: if you're using MyGet Build Services, then you are already using Chocolatey! That's right: all the tools mentioned in our Build Services docs are provisioned on our build agents using Chocolatey!

We also know some of our users are using MyGet to host their own Chocolatey repository, which in turn is just another NuGet feed. It just serves Chocolatey packages instead.

It goes without saying that we are huge fans of the Chocolatey project and we really want to encourage and support the Chocolatey team to take the project to the next level. If you're like us and love Chocolatey, we'd like to invite you to join us in backing the Chocolatey Kickstarter project! MyGet has pledged $750 to help move the project from experiment to experience.


Chocolatey has proven to be a huge time saver and invaluable tool for us, and if you feel the same, the least you can do is to get yourself a nice box of chocolates ;-)

Let's get Chocolatey!

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!

User-defined environment variables in MyGet builds

Sometimes you may want to pass in a value to the build scripts without hard-coding it into the build script. MyGet now supports setting additional environment variables (that can be used in custom build scripts as well as plain MSBuild). From the Build Source configuration, you can add up to 15 environment variables that will be made available during build.

Edit environment variables

The open/closed eye icon next to the environment variable can be used to show/hide the environment variable value in the build log. Sometimes it is not desirable to have things like passwords or API keys shown in the build log, and by making the environment variable hidden we’ll hide it in the build log.

Shown in build log

Happy packaging!

MyGet feeds now support Target Framework Filtering

On October 1st, the NuGet team enabled Target Framework Filtering in NuGet.org's Search API. We're happy to announce we've just flipped the switch in our back-end to enable this on MyGet feeds as well! Ever since version 2.1, the NuGet clients have been sending the consuming project's target framework in the search requests. Everyone who's using NuGet 2.1 or above is going to benefit from this server-side optimization.

What does this mean for you as a package consumer?

Since NuGet will now be filtering package search results by target framework, in a nutshell, you should no longer see this dialog when installing packages:

More details about this feature can be found on the NuGet blog.

I'm using upstream package sources. Does anything change?

Yes and no. Upstream package sources that support target framework filtering, like NuGet.org and MyGet.org, may return different (but better) results from what was returned previously. For other package sources, we will return search results the way we did before.

If the clients were sending this information to the server since v2.1, what took you so long?

We want MyGet feeds to be fully compatible with the NuGet API that lives at www.nuget.org. This means we want MyGet to provide a consistent behavior from a user/client perspective.

Happy packaging!

Notifications let you know when a package is updated

Call it human nature, but whenever an update to a software package is available we want to know about it and install it immediately. We do this with our computer, phone and even our NuGet packages. For good reason! The packages we depend upon may be updated because of bug or security fixes and even new features we want to make use of.

MyGet already supported automatically updating NuGet packages from upstream package sources, however we felt that this might not always be the best solution for all scenarios. We’ve now made it possible to receive e-mail notifications about package updates instead, allowing you to decide manually if you want to upgrade or not.

Update notifications per e-mail

E-mail notifications can be enabled from your feed’s Package Sources settings, editing the upstream package source configuring which actions should be performed and when.

NuGet update notifications

We will send you an e-mail (or perform an automatic update, or both) at the chosen interval. This helps you keep up-to-date and allows for an easy update of the package: after clicking a link in the e-mail, MyGet will show what the latest available version is and offers a one-click install.

Latest available NuGet package version

Happy packaging!

Introducing MyGet webhooks

One of the most requested features for MyGet so far is support for webhooks. We’re happy to announce MyGet webhooks (preview) is available today. Every MyGet feed provides the option to communicate with external services, such as a web server, whenever a specific action occurs on the feed.

Webhooks for 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.

Delivery log

Give webhooks at try! For more information, check our documentation website. We’re open for any feedback or feature requests you may have.

Happy packaging!

Configure a feed’s Report Abuse URL

Ever wondered where the “Report Abuse” link in Visual Studio navigated to? Or where it comes from?

Report Abuse URL

This link is available for every package, and on MyGet feeds, it will typically point to a dummy URL. The reason for that is it’s your feed, and you are the one who should respond to any messages that come in through it. But with a dummy URL, that obviously does not work… So we made it configurable! From your feed’s Package Settings tab, simply enter the URL Visual Studio should navigate to when clicked.

Configure Report Abuse link

This should make it easier to gather feedback on packages hosted on your feed.

Happy packaging!

MyGet now offered through the Microsoft Azure Store

Microsoft Azure

We are happy to announce that MyGet partnered with Microsoft to be included in the Microsoft Azure Store. This is our second partnership with them, since we also integrate with Visual Studio Online. The Microsoft Azure Cloud is widely used to build and deliver applications to end-users. Developing these applications could greatly benefit from using a package management solution to streamline development, and that’s where MyGet comes in.

Having MyGet available in the Microsoft Azure Store allows developers and team leads to create MyGet accounts for themselves or their team members, whether free or one of the paid plans. There are no separate bills to be paid: MyGet will be part of the monthly account statement or Enterprise Agreement.

imageIf you are a Microsoft Azure customer, here’s how to create a new MyGet account:

  1. Go to the Microsoft Azure Management Portal
  2. In the bottom toolbar, click New and select Store
  3. In the Choose an Add-on dialog, select MyGet and click next
  4. In the Personalize Add-on dialog select the MyGet plan you want to sign up for.
  5. If you want to create one (or more) paid subscriptions, you can use the promotional code STORELAUNCH, which will give you a 25% discount during the first 6 months of the subscription (code valid until end of August, 2014).
  6. Once the subscription is created, click Manage in the bottom toolbar and pick the username and password you wish to use for your MyGet subscription.

If you are an existing MyGet user and would like to make use of the Microsoft Azure Store integrated billing, contact support and we will make it happen!

Happy packaging!

Promoting packages generated during build

We’ve supported the “Push upstream” workflow for quite a while now. This workflow allows you to promote packages from one feed to another, ideal when you are pushing prerelease packages on one feed and pushing them as stable packages to another feed after testing them.’

So far, it has been only possible to push individual packages upstream, or all “latest” packages. We realized this was painful for one scenario: if you’re usign Build Services, it may be handy to be able to push just the packages generated by a specific build. And that is exactly what we’ve added now!

Promoting packages generated duing build

When expanding a build’s packages, a new menu entry Push upstream…is now available to push the packages generated by a build to another feed. This should greatly improve usability for this scenario.

Happy packaging!