MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

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!

Support for feed names with dashes and underscores

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.

Feed names with dashes and underscores

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!

Introducing activity streams

In a previous post we highlighted the new user profile page and briefly mentioned we are working on activity streams. If you look at the Activity tab of your profile, you'll still see that it is coming soon.

We are still working on the UI for this part, but before we introduce it to the masses we need to take care of a few more things. No worries, a clear communication about these changes will be done upfront, and we obviously will keep private feed activity secured. A lot of stuff is happening under the hood, really, in order for this feature to be rolled out smoothly. Our incremental and short release cycles are starting to pay off (or you'd end up with blank activity streams upon release).

However, you might notice that we already built an initial UI for the feed activity. Simply take a look at your feed details page and check the Feed Activity tab on the left menu.

We are working hard on providing you with historic information on packages and feeds throughout the site so expect more to come soon. We believe this will greatly improve the experience of both package publishers as consumers, as well as those interested to keep up with what's happening on the feed or with a specific package. There's some great stuff on some of the feeds in our Gallery and we'd like to give you the opportunity to get notified of the package repository events you want to track.

The below screenshot also gives you an idea of the kind of activity you might be interested in: adding or deleting packages, unlisting packages, pushing packages to an upstream package source (e.g. to NuGet.org), etc. The particular feed activity you can see below is the result of how we push the GoogleAnalyticsTracker package to NuGet.org.

Happy New Year & Happy Packaging!

Cloning feeds is now supported

It happens that for some reason you require a full copy of an existing feed. You may want to do some upgrades. Maybe you just require your development feed to be copied as a production feed or vice-versa. Our latest deployment provides you with a fresh feature: cloning feeds.

From the feed list (www.myget.org/feed/list), simply click the “Clone” button next to a feed. Note that this will only be shown for feeds that are owned by you.

image

After a couple of minutes, your feed clone will be up and running.

image

Happy packaging!

Introducing a new profile page

Our latest service deployment features a fresh user profile page. You’ll be able to see everything you need by just clicking the Profile link. You’ll be able to see your feeds, linked identity providers, payment history and more.

image

You can also look at other user profiles. Simply browse to the MyGet gallery and you’ll be able to find out who’s behind a given public feed.

image

Yes, you’re seeing what we’re up to: in one of our next releases, we’ll be providing you with activity streams that give you an overview of what’s happening on a given feed or by a specific user.

Happy packaging!

Package retention policies

So you’re pushing your packages from your build server onto MyGet. That must result into a large number of packages! Or you want to keep only the latest 2 versions of a given package? Have no fear, package retention policies are here!

Under your feed, navigate to the Package Retention tab.

image

By default, we keep all package versions available on your feed. If you would like to do some automated housekeeping, you can now specify the number of stable and prerelease packages to keep on your feed. Whenever a package is added to your feed, we'll make sure these retention rules are respected.

Happy packaging!

Add packages from GitHub, BitBucket and CodePlex using MyGet build services

We’re pleased to announce some new features to MyGet build services. This feature allows you to add packages to your MyGet feed from any Git, Mercurial (hg) or Subversion repository out there. We’ll grab the sources, compile, package and make sure the result is listed on your feed. While still in beta, the feature is starting to take shape. In our latest release, we’ve shipped some interesting new features related to build services.

From your feed details page, you can navigate to build services. The “Add build source…” button has been around since the start and allows you to enter details of the source code repository manually. Because that can be a bit clumsy and since most public source code repositories out there have API’s available, we now support linking GitHub, BitBucket and CodePlex repositories with the click of a button!

image

After clicking one of these, you’ll be redirected to the code hosting provider for login.

image

After that, you can just check the projects you wish to add and link them automatically.

image

Apart from being able to easily link projects from GitHub, BitBucket and CodePlex, we also improved the build server itself a bit:

  • Support for portable libraries
  • TypeScript SDK 0.8.1.1 has been deployed
  • Private repositories on BitBucket now can be referenced
  • Git repositories with submodules can now be built (do note the submodule must be available over HTTP/HTTPS)

Happy packaging!

NuGet package restore from a secured feed

One of the most frequently asked questions at MyGet is the following one (we have pending updates to our FAQ section):

How do I set up NuGet package restore against a private MyGet feed requiring authentication?

This is also one of the things you might end up doing when debugging NuGet package restore issues.

For public feeds, you only need to change the repository URL in the nuget.targets file to let your build server know from where it needs to fetch the packages. For private feeds however, there are a few things you need to know.

Which credentials should I use?

At MyGet, we recommend you to create a separate account for your build agents and give it specific permission on your feed (e.g. readonly or read/write, but no additional permissions).

It is not a technical requirement though: you could simply use your personal account, but please be aware that in this case you share your credentials!

As you'll see in this post, you can store the credentials for the build service account on the build agent(s) without having to share them with anyone. Using a user's account for the build agent can break anyone's build if access for this user is revoked...

Visual Studio will prompt for credentials

As soon as you try to communicate with a secured package source in Visual Studio, it will prompt you for credentials. So why do you get the following build error when using package restore?

There's no non-interactive way to provide credential parameters

NuGet package restore relies on the NuGet.exe commandline tool by using the install command. The commandline will either prompt you for credentials (which isn't suitable for automated build scenarios), or will look for credentials in nuget.config file in %AppData%\NuGet\nuget.config (if you use the Non-Interactive option).

The latter looks like what you need in automated build scenarios, but requires you to store feed credentials on the machine, for the user account that will perform the build. This can become cumbersome if you have a multitude of solutions using this feature.

Hierarchical NuGet.config doesn't take credentials into account (yet!)

The latest version of NuGet has support for hierarchical nuget.config files, which is an attempt to overcome the need to store everything on the machine. It allows you to have a solution-level NuGet configuration which should be taken into account during package restore.

This means that feed URL and credentials could be stored next to your solution instead of being pre-configured in the user profile. However, credentials aren't picked up (yet), and there's no easy way to store them (encrypted) into any nuget.config file other than the one in your roaming user profile (explained in the next section of this post).

This is a known issue which seems to be fixed in vNext of NuGet. Check this Codeplex issue for more details. Not sure though whether this will be facilitated without having to copy-paste those encrypted credentials from one config to another.

You can store feed credentials in your user-profile NuGet.config

That's likely to be the easiest approach: as you register the package source URL, you might want to save the required credentials as well. This is however not exposed in the Visual Studio NuGet Package Manager extension, so you'll have to use the NuGet.exe commandline tool. The following gist illustrates a few of these options that should help you configure your secured feed, including credentials.

MyGet Build Services - Public Beta

We’re happy to announce that MyGet Build Services is in Public Beta since, well, now. MyGet Build Services enable you to add packages to your feed by just giving us your Git, Mercurial or Subversion repo. We build it, we package it, we publish it. And starting today, every MyGet user can use it.

More information on MyGet Build Services can be found in a previous blog post, although some things have been updated. You’ve provided us feedback through our UserVoice, resulting in the following changes:

  • We now support .NET Framework 4.5. New features available in .NET Framework 4.5 are described at http://msdn.microsoft.com/en-us/library/vstudio/ms171868.aspx.
  • Build hooks! The list of your build definitions now shows a build hook URL which you can link to your GitHub or BitBucket repository. Calling this build hook (HTTP POST) will trigger a new build. Or in other words: a commit will trigger a build.
  • Our build server now checks for a file called build.bat first, then MyGet.sln, then your .sln and then .csproj/.vbproj files (UV)
  • We now support Git, Mercurial and Subversion repositories (UV)
  • You’ll now have some tools available in the environment variables (UV)
  • There’s more information in the build logs (UV)

Keep the feedback coming! Build Services are now enabled on every MyGet account. Do note MyGet Build Services are still a beta, and as Willy Wonka would say… “Little surprises around every corner, but nothing dangerous.”

Happy packaging!

PS: Why not deploy your freshly built apps using Octopus Deploy?