MyGet Blog

Package management made easier!


Improved build log viewer with error navigation

We have just deployed a newer version of our build log viewer. When using MyGet’s build services to compile and package NuGet, npm or VSIX packages, the build log viewer now has colored output as well as line numbers that have hyperlinks. Want to share a certain line in the build log with a colleague? Click the line number and send the link so they can open the build log right where you left.

By making less important build output less prominent and by highlighting more important messages, reading and analyzing the build log becomes much easier: less important messages have a gray color tone, normal messages are white. Warnings and errors are highlighted in yellow and red, making them much easier to spot.

Build log with colored output

When warnings or errors are found in a build log, MyGet now shows additional navigation buttons at the top. Next to the number of warnings or errors, the up and down arrows can be clicked to jump to the next important message in your build log.

Warning and error navigation

We’re looking forward to hearing your thoughts on this improvement. Let us know through the comments below or drop us a note via e-mail or Twitter.

Happy packaging!

MyGet by the numbers

As it is a slower time of year and many people are taking some vacation, we decided it would be a nice time to collect some numbers around MyGet. Of course we can’t share all of our statistics, but it’s always fun to look at them. MyGet has a shared tenant,, hosting and serving NuGet, npm, Bower and VSIX packages. And debugger symbols, of course. This shared tenant will be the focus of this post. Our MyGet Enterprise plans, which run on their own dedicated tenant infrastructure, are not included in these statistics.

Number of machines

Our web application is hosted on Microsoft Azure across three different regions. The shared tenant has its primary location in the West Europe region, and a secondary in US East. Both locations run 3 front-end web server machines and 2 back-end machines for handling anything that doesn’t have to happen real-time. These machines are all general purpose “A3” machines. We have a tertiary deployment in US West for some Enterprise customers, where a similar deployment lives.

Since we use auto-scaling based on time of day, we don’t have the same amount of machines throughout the day. On average, we run 10 machines for our front-end.

Another deployment lives in a private datacenter and hosts part of our build services. We also run our CI systems in this private datacenter. Azure is great, but also super expensive for some workloads. Hosting this workload ourselves reduces the operational cost for build services with a factor 6. This infrastructure is all SSD based, and we’re getting loads more horsepower out of the VM’s running here. To give an example: the Visual Studio 2015 Update 3 install ran for 4 hours on our Azure build agents, the private VM’s did the update in half an hour.

Number of packages and downloads

Our shared tenant currently hosts over 1 million unique packages. These packages have been downloaded 17,305,790,397 times so far. Yes, that’s over 17 billion. We handle roughly 400 million downloads each month. Some of our Enterprise customers are pushing similar numbers on their instances.

If we look at package types, roughly 50% of packages are NuGet and symbols packages, including Chocolatey and Octopus Deploy. 30% of packages are npm, with Bower and VSIX following at around 10% each.

Storage, traffic and bandwidth

Right now, our shared MyGet tenant consumes 3.2 TB of storage for just packages and metadata, including backups in secondary Azure regions.

Each month, users of push 2.4 TB of data into our system. Many feeds contain CI packages and retain only the latest 100 nightly builds. Other feeds contain 100 MB of Octopus Deploy artifacts, being updated daily. On the consumption side, we have 8 TB of traffic being consumed each month, spread across our Azure bill and the Switzerland-based KeyCDN.

We used to run off the Azure CDN, but found that KeyCDN has been more reliable at half the price. We still have the Azure CDN configured so we can fail-over in case it’s needed. So far, this hasn’t been required. Swiss efficiency #ftw!


When we first introduced build services, we envisioned making building NuGet (and later npm) packages as easy as possible. We have a number of open source projects running their builds on MyGet, as well as a number of companies enjoying the convention-based builds.

MyGet Build Services has produced over 65,000 successful builds (producing packages) so far. On average, these builds take 2 minutes to complete, with some people maxing out the 30 minute build time we allow.

Support requests

Ask any MyGet user and they will confirm we offer an excellent and speedy support. We typically manage to respond within the hour, unless we’re asleep. Which happens for a good 7 hours each day when night falls over the CET time zone. Our fastest response  so far providing a solution to the customer was 38 seconds.

We handle a good 45 support cases each day. Some of those are simple: we can often respond with a link to documentation. Others are more complicated and challenging. And if we can, we submit a PR to your project to resolve any code or configuration issues.

The busiest day of the week? Thursday. By far. It seems that is the day where everybody realizes the week is over halfway and things must be shipped. Unexpected to us, holidays are also quite busy. It seems many developers sneak in a few hours of coding time on those days and often want us to be part of that.

If we look at technologies, 80% of questions or client configuration problems are related to NuGet. 9% of requests are related to npm. And less than 1% for Bower and VSIX. What with the other 10%? These are typically orientation questions to see if MyGet is a good fit, or if MyGet fits in the customer’s architecture or development practice.

When we started this adventure, we never thought these numbers would become true. Thanks for making this happen and being a big part of this!

Happy packaging!

Setting an expiration time for your MyGet access tokens

From a security perspective, it is always good to have secrets that are only valid for a given amount of time. This ensures that these secrets have to be rolled over more often, resulting in a better overall security policy. Today, MyGet introduces expiring access tokens and API keys to accommodate this workflow.

From your profile page, you can manage your access tokens. The list of access tokens will always contain a primary key, and additional access tokens can be created.

Manage MyGet API keys

When creating (or editing) an access token, we can set a description to identify where the access token is being used. We can now also (optionally) set an expiration time after which the token can no longer be used. This can be done for additional tokens, as well as for the primary access token.

Create MyGet access key for accessing NuGet server

This change is live on all MyGet plans, so go ahead and set the expiration time for your access tokens!

Happy packaging!

Using build services to create Chocolatey packages

Chocolatey is a Machine Package Manager, somewhat like apt-get, built with Windows in mind. It lets us install software onto our machine, supports updates and dependencies, much like NuGet or npm do. MyGet has always supported feeds containing Chocolatey packages, making it easy to distribute software packages across teams or with customers. In this post, we’ll show you a trick on how to build Chocolatey packages using MyGet build services. It’s the least we can do as a Belgian company – our country is known for chocolates after all…

MyGet Build Services has a convention-type build approach that will create NuGet, npm and VSIX packages whenever required files or project types are available. By adding a build.cmd or build.ps1 file, this convention can be overridden – just the thing we want to do to create Chocolatey packages.

Using a little bit of PowerShell, we can call into Chocolatey’s choco.exe which handles packaging and verification. The following can be copy/pasted in a build.ps1 file in the root of a GitHub, BitBucket or VSTS repository:

Write-Host "Building Chocolatey packages..." $nuspecs = Get-ChildItem -Path $PSScriptRoot -Filter *.nuspec -Recurse foreach ($nuspec in $nuspecs) { choco pack $nuspec.FullName } $artifactsFolder = "./artifacts" Remove-Item -Path $artifactsFolder -Force -Recurse -ErrorAction SilentlyContinue New-Item $artifactsFolder -Force -Type Directory | Out-Null Move-Item *.nupkg $artifactsFolder Write-Host "Finished building Chocolatey packages."

Once a build is triggered on MyGet, this script will execute and create (and upload) Chocolatey packages to our MyGet feed, which we can then install on our system.

Happy packaging!

Using service messages to explicitly add a package to MyGet

MyGet build services is a convention-based build system that converts source code into NuGet, Npm and Vsix packages. It will compile code, run tests and collect the packages that were created and add them to your MyGet feed. Sometimes, for example when using custom build scripts or using gulp or grunt to run the build, we can’t always detect which packages were created. To add these packages to your feed, you can use service messages.

By writing a service message (a specially formatted string) to the build output, you can influence part of the build process. For example fail the build, update the version number, setting environment variables and so on. We recently added the publishPackage service message, which lets you specify additional packages to add to your feed when the build succeeds. The following example pushes the to your feed as a Bower package:

##myget[publishPackage path='' type='bower']

Check our documentation for additional options and remarks and give it a try. We’d love to hear your thoughts!

Happy packaging!

MyGet 2.1 Release Notes

MyGet 2.1 was released on February 12, 2016.


This 2.1 release of MyGet again adds some new functionality to the service. Major highlights of this release are:

This means, from now on, you can now also use MyGet to host your symbols, publicly or secured.

MyGet 2.1 Highlights


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:

  • Security: Feed privilege claim tokens now expire after 15 days when unused
  • Billing: we now allow for yearly billing to reduce the administrative overhead of billing cycles

MyGet Enterprise

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

  • Support for restricting feed creation to administrators only

MyGet Build Services

  • Support for explicitly publishing artifacts using service messages
  • Support for BitBucket API v2.0 and switch to OAuth 2.0
  • Support for xUnit v2.0
  • Support GitLab POST hooks
  • Performance improvements in build hook payload parsers
  • Web Hooks: new Build Queued web hook
  • New option: toggle access to build log for feed consumers

Bug Fixes

  • Various performance improvements in the web site
  • Bower: license analysis now also checks Bower package licenses
  • Usernames on feed security page now link to the user profile page
  • npm: proxy dist-tags from upstream when available
  • Fixed a bug where in some cases uploading a ZIP file Bower package threw an exception
  • Fixed a bug where in some cases pushing an npm package upstream to failed
  • Fixed a bug where editing a package source was not possible when the package source is unavailable

We love hearing from you, so keep that feedback coming! MyGet is built for you!

Happy packaging!

Two of my packages are treated as one. Help!

Every once in a while, our support gets a question that is similar to the following:

When requesting the package details for some versions of the NuGet packages in our feed it seems like the service encounters an error preparing the ATOM document, also resulting in NuGet failing to download the package.

Here's an example URL:'MyPackage',Version='1.2.20160209.1-master')

Is something wrong with MyGet? Definitely not! Let’s look at the packages for this feed:

  • MyPackage 1.2.20160209.1-master
  • MyPackage 1.2.20160209.1-dev

Can you spot the error? It’s very subtle, so let us help here. The version number has three dots (“.”) in it, which means it should be treated as a type of version number, which is numeric. MyGet takes the hint and will strip off the –master and –dev in the above versions, treating both packages as one.

Clearly, the intention here was to use Semantic Versioning (SemVer): the –master and –dev suffixes to the version number were intended to provide a label in the version number. But semantic versioning is in the form of major.minor.patch-label, which means one dot less in the version number should be used. So in this case, the packages should be re-versioned and re-uploaded with the correct version number.

Don’t you guys have validation for this? is one of the questions we’d expect. We do, but it’s opt-in because many of our users start out with non-SemVer packages on their feeds and we don’t want to block those from being uploaded either. From a feed’s Package Settings tab, enable the Forbid packages which are non-compliant with Semantic Version? option.

Forbid packages which are non-compliant with Semantic Version?

This will prevent malformed semantic versions from being uploaded to your feed and prevent the above error from ever happening to you.

Happy packaging!

Dropbox as a package source for NuGet, npm, Bower and VSIX packages

Wouldn’t it be awesome if creating a NuGet, npm, Bower or VSIX feed was as easy as just copying packages into a Dropbox folder? Awesomeness is here: we’ve added Dropbox as a package source type to MyGet. This allows us to link a Dropbox folder to a MyGet feed and automatically upload packages so they can be consumed with the popular package managers out there.

Synchronizing NuGet packages with Dropbox

The Dropbox package source makes it easy to move packages into MyGet. For example, migrating from a network share to MyGet is as easy as copy-paste. Have a build server that drops artifacts into a Dropbox folder? MyGet will add the synchronized artifacts to your feed. Right now we download packages from Dropbox on a schedule (every 15 minutes).

Give it a try and let us know how it goes – feedback is welcome through the comments below or via the MyGetTeam Twitter account.

Happy packaging!

Adding another MyGet feed as a package source - Feed presets

Many people are using multiple MyGet feeds in their development flow, and have good reasons to do so. Some are pushing packages from one feed to another as they promote them through quality gates. Others are proxying upstream feeds or filtering packages downstream.

MyGet supports many types of package sources, and as flexibility is great, configuration can be a little tedious or even error prone.
Why would we ask our users to provide us with their MyGet feed url if we know what feeds the user collaborates on? We realized we could do better. In addition to the already rich list of presets, we have added a convenient button that lists your MyGet feeds.

It works the same way as the presets, and will populate your package source name and URL. This convenience helps avoid wasting time configuring your package management workflow and ensures the upstream feed is configured correctly.

Happy packaging!

PS: At MyGet, reducing friction is a feature. One that we consider most important! After all, that's how we have been able to deliver a smooth package management experience, serving over 16 billion package downloads over the past few years. Have a feature request or an enhancement you'd like to see? Please reach out to us!

Improved support for localized satellite NuGet packages

At MyGet, we live and breath a culture of componentization, and we are very happy to see package authors adopting and sharing these practices within their organizations. One of these practices is the usage of NuGet's localized NuGet packages feature. The adoption of localized satellite packages is a good indicator of package author maturity. Using a better practice should be rewarding and free of friction. One of our Dear Users provided us with great feedback on how he leveraged MyGet to release localized packages by pushing them upstream. However, some unnecessary friction was involved, which had to be removed.

Localized NuGet Packages

As a NuGet package author, you can provide a localized experience for your libraries. The NuGet client has supported the creation of localized satellite packages since version 1.8.

For those unfamiliar with the concept, here's a basic package graph demonstrating the idea:


  • Meta package, installing My.Framework and all localized satellite packages
  • Depends on: all satellite packages (,, My.Framework.Core.el, ...)
  • Package containing an actual framework library (e.g. in lib/net45/My.Framework.Core.dll)
  • No dependencies for the sake of the demo (your libraries most likely have dependencies :))
  • 3 localized satellite packages for the My.Framework.Core package
  • Depends on the actual framework package being localized: My.Framework.Core.1.0.0-alpha0001.nupkg
  • Only contains localization resources (e.g. lib/net45/nl/My.Framework.Core.resources.dll, lib/net45/nl/My.Framework.Core.xml)
Or visualized in a graph, here's the dependency tree:

To facilitate discovery of these satellite packages, we added a convenient Localization tab on the package details page if localized satellite packages are detected.

Releasing localized NuGet packages

Ideally, releasing a package that has localized satellite packages from MyGet to another feed, should be a click of a button away, publishing the entire package-set at once. Optionally, one might also want to adjust the prerelease tag and release notes of this package set, either per package individually, or for all at once.

The Push Upstream feature (also check our docs) has been upgraded to now also detect package dependencies and localized satellite packages!

This means that, as in the above sample scenario, you can now publish the entire localized package-set in one go by pushing the My.Framework meta package upstream.

In addition, you can also edit (or simply remove!) the prerelease tag and/or release notes for each package individually, or for all of them at once!

Simply click the edit button  next to one of the packages, modify the fields, and click the water-drop icon  to apply the changes to all other packages in the dialog.

Of course, you can still exclude individual packages from this list if you want to by clicking the  button next to the respective package.

We love this kind of feedback and hope you find this change useful, so keep the feedback coming!

Happy Packaging!