We’re happy to announce we’ve completed another sprint. The main focus for this sprint was to start a redesign of our user experience. Next to that, new features have been introduced as well. Let’s have a look at what has changed and which cheese we moved.
A complete change log can be found on our new documentation site.
First steps in redesigning the MyGet experience
One of the first things you will notice when logging in to MyGet is that we’ve drastically changed the look and feel of the homepage. First of all, we decided the header we had earlier was too high and didn’t add much value. We’ve now condensed the header when authenticated. Your gravatar image will be shown and when hovering your username, a list of all feeds you have access to will be shown.

The initial view you get is an activity stream. This provides the latest information about your feeds as well as the packages on it. On the right side, we’ve added quick navigation to all your feeds.
The feed details page now features a couple of additional buttons: you can clone a feed as well as delete a feed from that page.

We’re planning on further improvements in our next sprint!
New features and improvements
The following new features have been deployed:
In the coming days, we will be blogging about these features in more detail.
The page load speed of MyGet has improved as well. We’ve been working on optimizing file sizes, compression and are using CSS sprites for many of our images.
We hope you like this new drop. Let us know your thoughts in the comments below!
Happy packaging!
With the latest version of the ReSharper 8 EAP, JetBrains shipped an extension manager for plugins, annotations and settings. Where it previously was a hassle and a suboptimal experience to install plugins into ReSharper, it’s really easy to do now. And what is really nice is that this extension manager is built on top of NuGet! Which means we can do all sorts of tricks…
The first thing that comes to mind is creating a personal NuGet feed containing just those plugins that are of interest to me. And where better to create such feed than MyGet? Create a new feed, navigate to the Package Sources pane and add a new package source. There’s a preset available for using the ReSharper extension gallery!
![image_thumb[1] image_thumb[1]](http://blog.myget.org/image.axd?picture=image_thumb%5B1%5D_thumb.png)
After adding the ReSharper extension gallery as a package source, we can start adding our favorite plugins, annotations and extensions to our own feed.
![image_thumb[3] image_thumb[3]](http://blog.myget.org/image.axd?picture=image_thumb%5B3%5D_thumb.png)
Of course there are some other things we can do as well:
- “Proxy” the plugins from the ReSharper extension gallery and post your project/team/organization specific plugins, annotations and settings to your private feed. Check this post for more information.
- Push prerelease versions of your own plugins, annotations and settings to a MyGet feed. Once stable, push them “upstream” to the ReSharper extension gallery.
Happy packaging!
Yesterday, the NuGet team released some improvements to searching the official NuGet package source. Today, you can also use this new syntax on your MyGet feeds!
This new search syntax allows us to narrow our search to a particular attribute of a NuGet package. For example, we want to search for packages which contain “Glimpse” in the Id, we can type “id:glimpse”. We can also search the description of a package and check if it contains any of the given words. For example “description:twitter bootstrap” will yield packages containing either the word “twitter” or “bootstrap” in their description.

Some example searches: (taken from the NuGet blog)
| Attribute | Example |
| id | id:jQuery |
| title | title:Validation |
| description | description:dependency injection |
| authors | authors:Outercurve Foundation |
| tags | tags:silverlight |
Enjoy, and as always…
Happy packaging!
Our 1.6 release shipped a number of interesting new features and enhancements to existing features, including those for MyGet Build Services. In this post, we’ll describe existing and new features and enhancements in a bit more detail.
One important thing to know is that Build Services is intended to make packaging projects easier. We are not aiming to become a full CI server like TeamCity of Team Foundation Server. That said, we do believe Build Services is appropriate for many scenarios and can take a lot of work out of your hands. We found some blog posts you may like: Nico Vermeir is using Build Services to package Windows Phone libraries. We also use it ourselves to push components from GitHub to NuGet.org.
Specify build configuration and platform
When creating or modifying a build source, you can now specify the configuration and platform that should be built. Easily switch between Release (the default configuration) or Debug or any other configuration that exists in your solution. The same goes for platform: if you wish to specifically build for x86, this can now be specified as the target platform.

Note that we also set a %Configuration% and %Platform% environment variable during the build process. This way you can make use of these in your customized builds that are run using a build.bat file.
Package versioning
In earlier versions of MyGet Build Services, we’ve been generating a random incremental version number for packages created during build. From now on, we have support for true incremental build numbers through the build source settings

The build counter starts with zero and increments with 1 on every build. You can also specify a version format ( Iuse '{0}' as a placeholder for the build counter) which will be generated during build. Note that if you enable the forbid packages which are non-compliant with Semantic Version option ,you should make sure the version format specified follows the Semantic Version rules.
We also set a %BuildCounter% and %PackageVersion% environment variable during the build process. This way you can make use of these in your customized builds that are run using a build.bat file.
Supported project types
We’ve added support for psake builds (use a built.bat file and invoke psake). Building Windows Phone 8 packages is now also supported out of the box. This brings us to the following list of supported frameworks and SDK’s:
- .NET 2.0, .NET 3.0, .NET 3.5, .NET 4.0 and ,NET 4.5
- PCL support (2012)
- Windows Azure SDK
- Windows Identity Foundation SDK
- Silverlight 4, Silverlight 5
- TypeScript SDK
- psake
Regarding test runners, we now support
- MsTest
- MbUnit 2, MbUnit 3
- NBehave
- NUnit (up to 2.6.2)
- xUnit.net
- csUnit
- RSpec
We believe adding these SDK’s out-of-the-box provides a lot of value to our users and we want to continue investing in expanding the number of supported SDK’s.
Environment variables
As part of the build process, we now set the following environment variables. Note that these are all read-only.
|
%BuildRunner%
|
Always "MyGet", can be used to determine if running on MyGet Build Services
|
|
%NuGet%
|
Path to a maintained-by-MyGet NuGet.exe
|
|
%SourcesPath%
|
Path to source code being built
|
|
%Configuration%
|
Build configuration (defaults to Debug)
|
|
%Platform%
|
Platform to build (defaults to blank)
|
|
%VersionFormat%
|
Version format specified in build configuration
|
|
%BuildCounter%
|
Build counter value
|
|
%PackageVersion%
|
%VersionFormat% with %BuildCounter% filled in, used as the auto-generated package version number
|
|
%EnableNuGetPackageRestore%
|
NuGet package restore enabled? Always true.
|
Other features
Some smaller features have been implemented for version 1.6 as well.
- When building from GitHub/BitBucket, a link to the changeset that has been built is available from the build services tab.

- Hanging build detection: whenever a build hangs for > 15 minutes, we kill the build process and set the build status to failed.
- The build log can be copied to clipboard.
- Build status is refreshed automatically.
Happy packaging!
We’re proud to announce support for the NuGet Package Source Discovery (PSD) draft on MyGet. Package Source Discovery (PSD) allows for NuGet-based clients tools to discover the feeds that are hosted by a user or organization by using the blog or website URL. Every feed hosted on MyGet has a discovery endpoint hosted at http://www.myget.org/Discovery/Feed/<yourfeed>.
In its simplest form, you can place a simple HTML tag on your website or blog and use that for discovering all feeds you own, whether on MyGet or another NuGet package repository such as TeamCity or the NuGet gallery.
Package Source Discovery
NuGet Package Source Discovery is an attempt to remove friction from the following scenarios:
- An individual user may have several NuGet feeds spread across the Internet. Some may be on NuGet.org (including curated feeds), some on MyGet and maybe some on my corporate network. How do I easily point my Visual Studio to all my feeds accross different machines? And how do I maintain this configuration?
- An organization may have several feeds internally as well as one on MyGet and some CI packages on TeamCity. How can this organization tell his developers what feeds they can/should use?
- An organization may have a NuGet server containing multiple feeds. How will developers in this organization get a list of available feeds and services?
For all scenarios, a simple feed discovery mechanism could facilitate this. Such feed discovery mechanism could be any URL out there (even multiple per host).
As an example, open Visual Studio and open any solution. Then issue the following in the Package Manager Console:
Install-Package DiscoverPackageSources
Discover-PackageSources -Url "http://www.myget.org/gallery"
Close and re-open Visual Studio and check your package sources. The URL has been verified for a PSD manifest URL and the manifest has been parsed. Matching feeds have been installed into the NuGet.config file, in this case all feeds listed in the MyGet gallery.
Discovery for your feed(s)
By default, we’ve enabled discovery on your profile page. For example, http://www.myget.org/users/maartenba provides discovery for all my (public) feeds. Of course, you can also create your own discovery URL on your blog or website: simply add a <link /> element to the HTML code. From then on, you or your users can use the following command to discover feeds from your website or blog:
Install-Package DiscoverPackageSources
Discover-PackageSources -Url http://<your website>
On your feed’s discovery page, we’ve added the HTML you have to add to your website to enable this scenario.

Discovery for gallery feeds
We’ve added a discovery on the MyGet gallery. When using http://www.myget.org/gallery as the discovery URL, all gallery feeds will be registered in your NuGet.config file. Every feed on the gallery in itself also provides discovery, for example ScriptCS has a discovery endpoint at http://www.myget.org/gallery/scriptcsnightly.
Please provide feedback on the Package Source Discovery specification. Comments on the MyGet implementation are also welcome!
Happy packaging!
By default, feeds on MyGet can contain any package that is added or pushed to them. Starting MyGet 1.6, we’ve added support for blocking certain packages from being added to your feed. To configure this, we’ve added a new tab on every feed.

This new tab currently features two options: “forbid overwriting of existing packages” and “forbid packages which are non-compliant with Semantic Version”. The first one is obvious: when enabled, MyGet will refuse overwriting existing packages on your feed. This makes it possible to achieve an important goal: have a guarantee that a given, known package is always exactly the same package in the future.
Enabling the “forbid packages which are non-compliant with Semantic Version” option allows you to block uploading of packages that are not SemVer compatible. Version numbers like 1.0.0 and 1.5.12559 will be allowed as well as 1.0.0-PRE. Package versions like 1.0.0.0 and 1.5.1.13369 will be blocked.
Happy packaging!
What do you do if you want to download all packages on your feed? We can do it using the Package Manager Console or by calling nuget.exe, but wouldn’t it be great if we were able to download an entire feed with the click of a button? That’s exactly what our 1.6 release added: support for downloading a feed as a ZIP file.
The feed list gives us a new button: “Download packages as ZIP”.

Depending on the amount of packages on our feed and the size of them, a ZIP file is download containing all packages in our feed:

There’s a lot of contents in this package. The readme.txt file contains some information about the moment the ZIP file was created and which packages are included.

Call it a convenience, but we also generate a packages.config file which can be used with nuget.exe to download directly from our feed in the future:

And of course, all packages on our feed are included in the ZIP file as well:

Happy packaging!
Good news: our package sources feature is out of beta after almost a year. The reason for that is that we wanted to make this a very stable feature which it proved to be thanks to many of our users testing it. But… what is this feature?
By default, MyGet uses the official NuGet gallery as the one and only source for packages. Package sources allows us to add additional sources for packages. For example if we want to use Chocolatey as a source for packages, we can add it as a primary or secondary package source. What’s more, we can also push packages from our MyGet feed to the upstream package source.

Let’s dive into some of the capabilities of Package Sources.
Adding a package source
Under the Package Sources tab of our feed, we can click the Add button to create a new package source. We can specify a name and URL to the package source, optionally provide authentication details and an API key for the package source. We can also select a preset package source, for example Chocolatey, a TeamCity server or a list of Windows 8 packages available from NuGet.org.

Optionally, we can also provide a filter. Filtering is based on the OData Filtering System. Valid filters are similar to Id eq 'jQuery' or IsLatestVersion eq true and Id ne 'Foo'. If we wanted to only be able to add packages which have the term “javascript” in their description, we can add the following filter: substringof('javascript', Description) eq true.
Throughout the context of your feed, MyGet will use the package sources in an ordered fashion. Reordering package sources to have a different default, for example, can be done by simply dragging items in the list.
Adding packages from another feed
After adding a package source, we can use it when adding packages to our own feed on MyGet.

We can select the package source to use from the dropdown and search the selected package source.
Feed proxying
Ever thought about having your own MyGet feed containing your company’s internal libraries and combining them with perhaps a filtered subset of the official NuGet package source? MyGet provides such feature out of the box, built on package sources.

When creating or editing a package source, we can tick the “Proxy package source” checkbox:

Note that also with the feed proxy, filtering the upstream feed is possible. For example, the filter string substringof('wp8', Tags) eq true that we used will filter all upstream packages and only include those where the tags contain “wp8”.
From this point forward when searching packages in Visual Studio, we’ll be able to see our own packages enriched with packages from the official NuGet package source:

Instead of working with a number of NuGet feeds, your development team will just work with one feed that is aggregating packages from both MyGet and other package sources out there (NuGet, Orchard Gallery, Chocolatey, …). This centralizes managing external packages and makes it easier for your team members to find the packages they can use in your projects. Management of packages that can be used by your team is centralized by this feature.
Push upstream
Each 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 NuGet.org (or another repository). No need for such bloated process: MyGet will perform the push for you.
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. In the package source, simply make sure to provide an API key and you’re all set to make use of this feature. 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. You can also modify the prerelease tag if needed (for example for promoting a prerelease to a stable package version).

Click “Push” and MyGet will take care of pushing the package to the selected package source.
Happy packaging!
An often requested feature for MyGet was support for feed names with dashes and/or underscores. With our 1.6 release we introduce just this: support for feed names with – and _ in their name.

Many people asked us for this feature. The main scenario these users referred to was having feeds for development and production, having feeds per branch and so on with a recognizable prefix.
Since we deployed it in our staging environment, we’ve been using it continuously ourselves. Every support request that comes in and requires investigation is prefixed with “support-“. When we develop a new feature and test it on a given feed, we typically prefix those feeds with “dev-". I even saw a “chuck-norris-was-here” feed appearing during development. We hope you like this as much as we do!
Happy packaging!
Many users have asked for us to provide release notes for everything we put online. Since that’s a great idea we’ll start doing this with the current 1.6 release which has been deployed earlier this week. But before we dive into that, let’s give you some hints about our development process and versioning system.
Our development process and versioning system
If you look at the footer of our website, you’ll have seen the following for the past few weeks already:

That’s right: we’ve been on (parts of) version 1.6.x for the past few weeks already. The reason for that is we version after our sprints and do continuous deployment of most things we work on. This means that when we start deploying features for our v1.7.x sprint, we’ll already update the version number in the footer to that number yet we’ll provide release notes only at the end of our sprint. So while today, you may already see v1.7.x mentioned in our footer because we've already deployed some features from that sprint, the following release notes are valid at time of writing this post.
Release notes for MyGet 1.6
MyGet 1.6 was released on February 25, 2013.
Features
MyGet
- Minimum length for usernames has been decreased to 3 characters (previously 6). Shorter usernames are now possible.
- A new menu item under feed: "Feed Settings" will contain settings specific to how MyGet handles packages for a given feed.
- Feed settings contains an option to enable/disable overwriting of packages on the feed
- Feed settings contains an option to enable/disable validation on the package version number with regards to Semantic Versioning
- Dashes and underscores in feed names are supported. Feeds can be named foo-prod for example.
- Download feed as ZIP.
- Package Sources are out of beta.
- API key in package source configuration is now masked
MyGet Enterprise
- Block e-mail addresses not belonging to the organization.
- Users can be made administrator.
- User removal (with the option of transfering their resources to another user).
MyGet Build Services
- Copy build log to clipboard.
- Specify build configuration and platform (Release/Debug and Any CPU/Mixed Platforms/...)
- Support incremental build numbers.
- Support configuring the build number using a template. Register version number as an environment variable.
- Support building Windows Phone 8 projects.
- Hotlink commit on GitHub/BitBucket from the build list.
- Refresh build status automatically.
- Support creating tools packages.
- Hanging build detection.
- Install psake on the build servers.
Bug Fixes
- Copy to clipboard on feed details page did not work in Chrome version 24.0.1312.57 and up.
- Feed statistics are not updated in some situations.
- NuGet Package Explorer always shows prerelease packages in the feed list.
- Build Services: building from protected SVN repositories isn't always working.
- Build Services: GitHub API only returns 30 repositories.
Happy packaging!