MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Improved search syntax in NuGet client... and on your MyGet feeds

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.

NuGet improved search syntax

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!

Build services - an overview

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.

Build configuration and 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

Specify package version number

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.

image

  • 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!

Support for Package Source Discovery draft

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.

image

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!

Require semantic versioning for packages pushed to your feed

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.

Package settings semantic version

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!

Download feed as ZIP

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”.

Download all packages from MyGet feed

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:

ZIP file download of NuGet feed packages

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.

Readme file

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:

Packages.config

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

NuGet packages in ZIP

Happy packaging!

MyGet Build Services - Package Versioning Explained

At MyGet, we do everything possible to reduce friction. It's in our DNA! Package versioning is currently the biggest roadblock you'll encounter when setting up a solution to automate package creation.

Versioning semantics

A NuGet package is uniquely identified by its package identifier and its version. This implicit requirement is often overlooked upfront and requires some thinking to define a proper versioning strategy. Luckily for us, some smart people already came up with something called Semantic Versioning (SemVer). We strongly believe in SemVer's pragmatic approach towards API versioning and the benefits that come with it.

Even though NuGet does not fully support the entire specification yet (the SemVer specification is still RC), it already has some features that allow you to benefit from using SemVer. An example of that is the Update-Package -Safe command option, which allows you to update your consumed packages to the latest safe package version: updates are constrained to the same Major and Minor package version. The only drawback of this feature is that you have to count on a safe versioning scheme applied by the package author. This is not guaranteed on the NuGet Gallery.

Build Source Configuration

If you set up MyGet Build Services for your feed, you'll get automatically created packages pushed to your feed. This implies automatic versioning. We've added some new capabilities to our Build Services in our recent MyGet v1.6 release. For one, we've added a UI to define the versioning scheme to be used.

You are in control

The biggest improvement is the fact that the build source now remembers the build counter for you, so you don't have to deal with maintaining a version.txt file or anything similar in your source repository. Of course, if you really want to, you still can: we're removing friction, not features! The build counter can easily be reset using the reset link. Similar to what popular build servers do (and any decent build server should do), you'll be able to define a versioning scheme using a placeholder for the build counter. You've now gained more control over the versioning "magic" we applied before.

In addition, you can gain full control by hooking into the build process. MyGet Build Services scans for the following source artifacts (in order of precedence):

If you provide your own build.bat script or MyGet.sln, you specifically instruct MyGet Build Services how to act on your sources. This also means you'll need to take care of versioning yourself. That's why we provide you with the following set of parameters so you can benefit from using the versioning scheme you already defined, as well as the build-counter attached to your build source. Note that these environment variables are read-only and are reset to the initial values at the start of the build process.

%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.

 

Package Source Configuration

We've also pulled Package Sources out of beta for everyone to enjoy, including our Free users! Package sources play a key role in the MyGet Build Services workflow. By default, the NuGet Gallery is configured as an upstream package source. You could obviously also configure Chocolatey, an Orchard feed, or your own MyGet feed, or all of them! These upstream package sources allow you to reference or mirror packages onto your own feed. It also allows you to easily push packages from your feed to the the upstream package source, given you configured your API key in the package source configuration.

When you want to push a package upstream, you'll be prompted with a dialog asking you which upstream feed should be used. In addition, you'll also get the opportunity to modify the package version as it should appear on the upstream package source. Note that no compilation is happening, we're simply adjusting the package version if you changed it. Because semantically nothing changed to the package, you'll only be able to change the -PreRelease tag, or simply remove it and make your upstream package a full release.

Without enforcing them

We won't enforce you in using SemVer as this would introduce friction for those who don't want to use it. It's not up to the repository host to define your versioning approach: this is the responsibility of the feed owner. This is impossible on NuGet.org as the feed is owned by the Community, which is definitely not organized around a single common versioning scheme.

However, if you - as a MyGet feed owner - want to enforce it, then you can by simply checking the appropriate checkbox in your feed settings. We try to find a balance between removing friction and providing freedom in your choices, so we hope you like it! Don't hesitate to send us your feedback or log them on our UserVoice.

Happy Packaging!

Package sources feature out of beta

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.

Package sources list

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.

Add package source

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.

Add package from another feed

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.

Proxy an upstream package source

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

Proxy feed

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:

Add package from feed

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.

Push package upstream

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).

Push package from MyGet to NuGet

Click “Push” and MyGet will take care of pushing the package to the selected package source.

Happy packaging!

New features in MyGet Enterprise

The MyGet Enterprise plan was introduced a couple of months ago and has had several management options since then. After logging in to your MyGet Enterprise instance the main menu displays a Dashboard link which gives the plan administrator access to a management dashboard.

MyGet Enterprise administration

In the management dashboard, MyGet Enterprise administrators can view statistics on their instance (number of feeds, storage usage, some aggregates on consumption and so on) as well as manage several options for their instance such as managing users, feeds, Google Analytics integration, SymbolSource integration, SMTP settings and quota management. With the 1.6 release of MyGet, we’ve added several other options to this enterprise management dashboard. And of course, your MyGet Enterprise plan also contains all of the enhancements that were introduced on the public MyGet website as well (such as retention policies, feed activity logs, build services, download as ZIP and much more).

Block e-mail addresses not belonging to the organization

Enterprise users not using Active Directory integration but instead relying on social identity providers like Microsoft Account or Google Account previously had no option for blocking users not belonging to their organization from creating an account on their MyGet Enterprise instance. Starting today, domain names for e-mail addresses can be whitelisted or blacklisted.

image

If your enterprise has Google Account e-mail addresses which all end in “@acmecorp.com", adding a whitelist entry for “acmecorp.com” will allow only those users to create an account on your MyGet Enterprise plan. Multiple entries can be entered, separated by a semicolon.

Users can be made administrator

Before our 1.6 release, multiple administrators per MyGet Enterprise instance were already a possibility but could only be managed by sending our support people an e-mail. Because this is a common task, we now made it possible for existing MyGet Enterprise administrators to grant or revoke administration privileges to users in their organization.

image

User removal

What happens if a user for a MyGet Enterprise instance leaves the organization? With our new release, users can be deleted from a MyGet Enterprise instance by clicking the Delete button on the user management pages.

image

By default, the user and its feeds will be removed. This is not always something you will want to do: what if that user is the owner of a production MyGet feed? The delete user dialog allows you to transfer feed ownership for all of the user’s feed to another user in your organization.

More information about our MyGet Enterprise plan can be found on the MyGet Enterprise plan page.

Happy packaging!