MyGet Blog

Package management made easier!


A very useful MyGet PowerShell suite

We recently shed a light on how you can easily use additional build tools on MyGet Build Services. However, there is more. A lot more!

We always say how much we love our users and this blog post is yet another illustration why we do. One of our users, Peter Rekdal Sunde, created an awesome PowerShell utility pack to make it even easier to customize your MyGet Build Services experience. The result is a complete build suite for creating NuGet packages and interacting with the MyGet Build Services environment. The scripts not only work on MyGet but also on your local development computer (you do need to have msysgit installed though). The entire code base was generously opensourced (MIT license) and is available on GitHub:

How does it work?

Simply include the myget.include.ps1 script in your build.ps1 on MyGet and use the provided functions.

Where do I begin?

To illustrate its purpose, we provide you a glimpse at some of the functionality provided by these scripts:

Build agent communication

  • MyGet-Write-Diagnostic - writes a diagnostic message to the standard output
  • MyGet-Build-Success - report build success
  • MyGet-Die - report build failure

NuGet utility functions

  • MyGet-NuGetExe-Path - path to NuGet.exe
  • MyGet-NuGet-Get-PackagesPath - returns the value of the repositoryPath attribute in nuget.config for a given project folder

Build steps

  • MyGet-Build-Bootstrap - starts a build (including NuGet package restore)
  • MyGet-Build-Solution - starts a build of a solution file
  • MyGet-Build-Project - starts a build of a project file
  • MyGet-Build-Nupkg - creates a NuGet package based on a specified .nuspec file. The .nuspec can contain additional replacement tokens, taking benefit from some of the variables provided by default by MyGet Build Services. More information at

Test runners

  • MyGet-TestRunner-Nunit - invoke NUnit
  • MyGet-TestRunner-Xunit - invoke XUnit

We recommend you to check out the readme and the samples for a detailed view of what's available though. Especially the test runner support is really nice, just check the below example!

Thank you Peter!

Happy packaging!

MyGet Year in Review 2013

2013 was a good year. We had tons of fun developing MyGet and judging from the feedback we get from you we can tell you are having fun with MyGet as well. And that is awesome! Thank you so much for sharing your feedback and your continued support!

Speaking of feedback: what do you think our 2014 roadmap should look like? Let us know through this survey!

Looking back at 2013 also involves some numbers, so here goes:

  • Average response time went from 3 081 ms back in January to 538 ms in December. That's almost a factor 6 improvement! Now let's scale those improvements to various other components of MyGet.
  • Average uptime in 2013 was 99.83%. We had 6 out of 12 months with 100% uptime. That's not too bad knowing that we combine various components with a 99.99% service availability each. Full history can be found on our status page.
  • Despite a 5min glitch on October 10, we have to go back to September 12 to find our last service issue caused by a circular package dependency, which in turn caused our package retention rules engine to choke on it. Measures have been taken to prevent this from happening on MyGet and a full root cause analysis is available on our blog.
  • We are now hosting 2394 feeds (excluding the Enterprise plan feeds), good for 85.000 unique packages and 40 GB of storage (plus 3 months worth of backups, that's 600 GB in total). Bandwidth is currently just below 1 TB a month.
  • Build services has ran 4.800 builds this year, and we're seeing quite some growth there over the last months.

Even though we deploy continuously, we tagged the following releases in 2013:

  • MyGet 1.5 (January 5th): new profile page, activity streams, feed cloning, package retention policies, CodePlex and BitBucket integration in MyGet Build Services.
  • MyGet 1.6 (February 25th): feed setting for SemVer validation, download feed as ZIP, package sources out-of-beta, lots of improvements to build services (versioning, SDKs and tools, logs, ...)
  • MyGet 1.7 (May 17th): new documentation site, search and filtering enhancements, NuGet 2.5 compatibility, Package Source Discovery, auto-publish symbols feed-setting, build service enhancements (assemblyinfo-patching, links to produced packages, support for build.ps1/.cmd/.bat, build parameters)
  • MyGet 1.8 (September 10th): NuGet 2.7 compatibility (new package restore!), auto-update metadata from upstream packages, package pinning, source labeling when pushing packages upstream, automatic package mirroring for feed-proxies, build services enhancements (build labeling compatible with GitHub releases, support for MyGet.ps1/.cmd/.bat).
  • And the obvious bug fixes (and occasionally new bugs) along the way...

We also shipped our second book: Pro NuGet, 2nd Edition (October 7th), packed with tons of new stuff and a dedicated chapter of recipes. Thanks again to Apress and the NuGet team for the high-quality reviews and helping us ship what is probably the most complete NuGet guide out there.

Let's make 2014 another great year for MyGet, NuGet and dependency management in general!

Happy New Year! And happy packaging!

PS: Let us know your feedback on what you want from MyGet in 2014 through this survey!

GitHub Releases and MyGet Build Services

During the summer, GitHub added a great feature for many projects: releases. Projects on GitHub can create a release and label sources, add binaries and release notes. Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.

Since MyGet Build Services supports labeling and we can label sources when pushing packages upstream, GitHub Releases make a great combination with MyGet! Let’s see.

Labeling Sources from MyGet

When enabled in the build source configuration on MyGet, source code can be labeled with the build number. This can be done for successful builds only (recommended) as well as for failed builds.

Label Sources during Build and make it a GitHub release

It is also possible to base tags for GitHub Releases on having a fresh package pushed to, say, This can be done while pushing packages upstream or “promoting” them. A dialog will provide you with additional options, e.g. configure the package version to be used upstream, as well as the option to label the sources for packages originating from MyGet Build Services.

GitHub release when pushing to

Releasing through GitHub

Regardless of the approach taken for creating a label, all that is left now is creating the release on GitHub. Since either the build process or the package promotion process have created the label already, all that GitHub requires is a set of release notes and a description for the release.

Integrating GitHub Releases and MyGet

Pretty sweet, no? Let us know your thoughts through the comments below or in our forums!

Happy packaging and shipping!

Using additional tools in the build process

Out of the box, MyGet Build Services supports building projects that depend on various SDK's and/or test runners. A full list of supported project types and SDK's at your disposal is available on our docs.

However, sometimes you run into a missing tool or SDK you absolutely need to compile your projects. Or perhaps you need a different version than the one available by default. If that's the case, you have two options:

  • Download the tools you need and commit them to your own repository
  • Use the brand new MyGet Build Tools repository on GitHub as a submodule to your repository

The first option is likely what you're doing today and allows you to cherry-pick the required tools without polluting your build with tools you don't need, making the build process faster.

The second option will bring down the tools from this repository during a build while they are technically not in your own GitHub repository. It currently contains the following tools:

  • NuGet 2.5, 2.6, 2.7, 2.7.1
  • NUnit 2.6.2
  • XUnit 1.9.6
  • curl

To add a submodule, run the following from your repository root (make sure you use the https endpoint):

git submodule add myget

From then on, you can use the tools from the myget/tools folder in your builds. For example, NuGet 2.5 can be used by calling myget/tools/nuget/2.5/nuget.exe.

Happy Packaging!

Making your life easier with multiple access tokens

What if you are using your API key on your TeamCity server and several other locations and for some reason you have to reset that API key? Major headache? Not anymore: from now on, MyGet supports multiple access tokens.

Since MyGet day one, we’ve had support for two credentials linked to your account. The primary API key could be used when publishing packages with NuGet.exe or NuGet Package Explorer while your username and password were useful when consuming private feeds from Visual Studio or a build server.

Additional access tokens can be generated from your profile page. The primary API key can be regenerated and new tokens can be easily created or revoked. Access tokens can be given a short description: this will help keeping track of where you used the access token and revoke it if necessary.

Access tokens can be used for all authentication purposes. They can be used when pushing to your MyGet feed or as an alternate password when authenticating against a private feed or

Go ahead and separate the credentials you use personally, on the build server or in other software. Access tokens can be created and revoked at any time.


Happy packaging!

Labeling Sources after Build

When enabled in the build source configuration on MyGet, source code can be labeled with the build number. This can be done for successful builds only (recommended) as well as for failed builds.Labeling Source Code from MyGet

The label originating from MyGet will always be named in the form vX.Y.Z, vX.Y.Z.P or v.X.Y.Z-pre. The description for the label will always be the label name (the version number), followed by "- MyGet Build Services". This labeling scheme is compatible with GitHub releases and can link a given NuGet package version number to a GitHub release.

An important note: If you enable build labeling on build configurations that have been created before 2013-09-11, you will have to specify credentials to connect to the remote repository, or remove and add the build source again. Builds with labeling enabled will fail if this is neglected.

Let us know what you think about this feature through the comments below or in our forums!

Happy packaging!

NuGet Package Restore and MyGet Build Services

With the release of NuGet 2.7, a new way of doing package restore came to life. Package restore allows you to keep only your source code and packages.config under source control and just download and install NuGet dependencies during build.

What does this mean for MyGet Build Services? Let’s say we’re making it easier for you! When building from a Visual Studio solution or project, there is nothing you should do: we will run package restore automatically. Let’s dive into the package restore conventions we have in place. Full details on the build process are available from our documentation.

MyGet Build Services

Package Restore Conventions

MyGet Build Services runs NuGet Package Restore as part of every build of solution or project files even if it's not enabled for the solution. Note that package restore is not run for builds making use of batch or PowerShell scripts. In those cases, you are the responsible for running package restore.

In order of precedence, the following package restore commands are run. When one succeeds, package other commands will be skipped.

  • nuget restore MyGet.sln -NoCache -NonInteractive -ConfigFile MyGet.NuGet.config
  • nuget restore MyGet.sln -NoCache -NonInteractive -ConfigFile NuGet.config
  • nuget restore <your solution file> -NoCache -NonInteractive -ConfigFile MyGet.NuGet.config
  • nuget restore <your solution file> -NoCache -NonInteractive -ConfigFile NuGet.config
  • nuget restore packages.config -NoCache -NonInteractive -ConfigFile MyGet.NuGet.config
  • nuget restore packages.config -NoCache -NonInteractive -ConfigFile NuGet.config
  • nuget restore MyGet.sln -NoCache -NonInteractive
  • nuget restore <your solution file> -NoCache -NonInteractive
  • nuget restore packages.config -NoCache -NonInteractive

If you are working with other feeds than the default feed, there are some options available.

Restoring from other Package Sources

If you want MyGet Build Services to restore packages from a specific feed, there are several options available to do this. The easiest way of making a package source available to the build process is by adding it through the UI.Making package source available during build

Using the Add package source button, you can add any feed that you want to make available during build: a Chocolatey feed, a TeamCity feed or another MyGet feed. It is even possible to store credentials so an authenticated feed can be used during build.

If you prefer to have all feed information in your source repository, that’s an option too. Adding a MyGet.NuGet.config file to your repository is the key to success. See the NuGet docs for more information on how such file can be created. The following is a sample registering a custom NuGet feed for package restore.

<?xml version="1.0" encoding="utf-8"?>
    <add key="Chuck Norris feed" value="" />
    <add key="All" value="(Aggregate source)" />


A small remark: if you have an authenticated feed but do not wish to add credentials to source control, credentials can be added to the feed's package source. These credentials will be available during build and allow you to consume a protected feed with ease. Authentication of feeds


Using NuGet Package Restore in MyGet Build Services is a breeze. We follow standard NuGet conventions to do your builds and allow adding package sources which will be made available during build through the UI. If you do need to customize things, there are several hooks available too. Full details on the build process are available from our documentation.

Let us know what you think about this feature through the comments below or in our forums!

Happy packaging!

How SharpDevelop uses MyGet and NuGet

This is a guest post by Matt Ward, working on SharpDevelop, an open source Integrated Development Environment (IDE) for .NET applications which supports the development of applications written in C#, Visual Basic.NET, F# and IronPython. It is and written in C#. In this post, Matt shares their story on using MyGet to host and discover add-ins for SharpDevelop.

If you would like to share your story too, let us know! We love to hear good stories!

SharpDevelop NuGet MyGetThe SharpDevelop team recently announced a new Addin Manager for SharpDevelop 5 and an online gallery for addins that is hosted on MyGet.

SharpDevelop has been extensible through addins since it was first created but it has never before had an online gallery. The majority of IDEs have an online gallery that can be used to find and install extensions. WebMatrix is one example that provides extensions through from its own NuGet feed just like SharpDevelop.

Addins for SharpDevelop 5 can now be published as NuGet packages to a MyGet gallery. NuGet gives SharpDevelop all the benefits of versioning and updating addins whilst MyGet provides a central place where SharpDevelop addins can be found and installed from.

SharpDevelop's addin gallery on MyGet is a community gallery which is open to anyone to publish their own addins.


About a year ago there was a discussion on the SharpDevelop mailing list about having an online source of addins for SharpDevelop. Andreas Weizel had started work on a way to obtain addIns from an online source but at the time it was not based on NuGet. Christoph Wille, Project Manager for SharpDevelop, suggested looking at re-using the NuGet gallery for hosting the packages and using NuGet to download and install addins. One idea was to put the addins on the main feed and add a special tag to them to distinguish them however it made more sense for SharpDevelop to have its own gallery. Rather than setting up a server and hosting a NuGet gallery ourselves it was quicker and easier to use MyGet.

Now let us take a look at how you can make your own addins available for SharpDevelop 5. If you have published a NuGet package to the gallery hosted on then the following procedure will be very familiar.

Publishing an Addin with MyGet

Here we will look at the steps taken to publish an addin that provides support for compiling against Mono. The source code for this sample addin is available on GitHub. The first step is to compile the addin. With the Mono addin compiled we need to create a .nuspec file that will be used to generate a NuGet package containing all the files needed for the addin:

    <?xml version="1.0"?>
    <package xmlns:xsd="" xmlns:xsi="">
        <metadata xmlns="">
            <authors>Matt Ward</authors>
            <description>Mono support for SharpDevelop</description>
            <summary>Mono support for SharpDevelop</summary>
            <file src="..\..\..\AddIns\Samples\Mono.Addin\**\*.*" target="" />

In the above .nuspec file we are adding all the addin files, including any subdirectories, by using the double wildcard ** so we do not have to explicitly specify every file. SharpDevelop requires the main addin assembly and its associated .addin configuration file to be in the root of the NuGet package. This is why the target for these files defined in the .nuspec file has been left empty.

Now we can generate the NuGet package by running NuGet.exe from the command line:

nuget pack mono.nuspec

On running this command you will see a "Assembly outside lib folder" warning which can safely be ignored since we are not going to be adding this NuGet package to a .NET project. We have now generated a Mono.1.0.nupkg file which is what we will publish to the MyGet gallery.

To publish to MyGet you will need your MyGet account's personal API key. Your API key can be found under Account Settings in the Security section. Copy your API key and in the following command line replace the Your-API-Key with your key:

Running the above command will publish the Mono addin to MyGet. Now anybody using SharpDevelop 5 can install the Mono addin by selecting AddIn Manager from the Tools menu.


You can see the list of available addins by clicking the Available section of the dialog. To install the Mono Addin select it and click the Install button. The addin will be available after SharpDevelop is restarted.

Matt Ward is developer at Pebble Code. In his spare time he works on SharpDevelop, which he has been involved with since 2004, and more recently has been working on a NuGet addin for MonoDevelop and Xamarin Studio.

Blog: Twitter: @sharpdevelop

Automatically mirror packages from other feeds (or: keep working during NuGet outages)

imageMany of our users have created their own NuGet feed on MyGet and are uploading their own packages to that hosted feed. Some of our users have been asking for a good way to make their MyGet feed the only feed in their team, the reason for introducing MyGet package source proxy which can include packages from upstream package sources such as the official NuGet Gallery in search results.

Up until recently, package source proxies were nothing but proxies: the feature simply proxies the packages on demand, which means a number of things:

  • Upstream packages that are deleted are no longer available on your MyGet feed unless explicitly mirrored.
  • When an outage occurs on the upstream package source, the proxy is of no use because it can’t connect to the upstream package source

Today, we are introducing a solution for that: a new option is available to automatically add and mirror downloaded upstream packages to your feed, as requested in these two UserVoice entries.

Enabling this option ensures that you can keep working with just one feed and have all the packages you need available on that feed, even if they originate from another package source and even if that upstream package source happens to have an outage. If you are working with firewall exceptions, enabling this option will also ensure that only one firewall exception to your MyGet feed has to be made.

If you want more information on how to enable this feature, check out an end-to-end tutorial in our documentation.

Happy packaging!

Build services: patching AssemblyVersion attribute

It already was possible to work with true incremental build numbers for packages produced using Build Services through the build source settings. A build counter starts with zero and increments with 1 on every build. You can also specify a version format (use '{0}' as a placeholder for the build counter) which will be generated during build.

Build Services recently got an update where the AssemblyVersion attribute can be patched with this version number. This can be enabled by checking the Automatically patch AssemblyInfo option in the build source configuration.

Patching AssemblyVersion during build

When enabled, MyGet Build Services will patch AssemblyVersion attributes in C# and VB.NET code. We are using Roslyn as the engine for parsing and updating attribute values. This approach is much more reliable than the regular expression based approaches most build systems use.

Two attributes will be patched: AssemblyVersion and AssemblyInformationalVersion.

  • The patched AssemblyVersion version is always in the form major.minor.patch. A package version 1.0.0 as well as 1.0.0-pre will yield an AssemblyVersion of 1.0.0.
  • The patched AssemblyInformationalVersion version supports semantic versioning and can be in the form major.minor.patch as well as major.minor.patch-prerelease.

Patching of these attributes will occur whenever the feature is enabled, no matter which build process is used (solution, project or build.bat).

Happy packaging!