MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Package mirroring is now enabled by default

Any service can experience a brief moment of downtime. This is also true for any upstream package source you configure in MyGet. That's why we have the package mirroring feature: when uploading or adding a package to your feed, the added package (and its dependencies) are stored into MyGet's own storage system and they remain available in the event of an upstream service outage.

This package mirroring checkbox used to be disabled by default. Why? Because we wanted to save on storage costs. You might think we were being cheap here, but today we are hosting over 50Gb of packages and serving many of them multiple times a day! In the early days of MyGet, it made sense to simply reference the packages from eg. nuget.org and redirect you to the package URL upstream. This has saved us quite some storage, bandwidth and backup costs whilst bootstrapping (you know the Free plan isn't free for us, right?).

However, as we are maturing, we also gain new insights in how you are using MyGet so we can more effectively reduce friction in the way you work with packages. We measured that 95% of our users are mirroring their packages, so we are now reversing the logic for it. As of today, the checkbox will be checked by default!

A popular question we get is: why aren't you hosting an entire mirror of nuget.org? Answer: this is another one of those backlog items that has been sitting around for years, and we believe NuGet API v3 will greatly facilitate such scenario. One day :)

Happy packaging!

Announcing Visual Studio Online integration

We are really excited to announce that as of today, MyGet enables new scenarios for all users of Visual Studio Online! Microsoft just announced Visual Studio Online Extensions at TechEd, so we can finally disclose these new scenarios and toggle the feature-switch for all of you.

In short, these are the new scenarios we've just enabled for you:


New to MyGet? Interested in using the Visual Studio Online integration? Why not make use of our TechEd 2014 offer that gives you a complimentary 2-month Starter plan!

New Scenario: Serve NuGet packages from a Visual Studio Online drop location

Having a VSO Build Definition creating NuGet packages but having trouble consuming those? You can now very easily create a MyGet feed and serve those NuGet packages by having us fetching them from your Drop Location! Optionally, we can post notifications to your VSO Team Room so your team gets informed about new package availability as the result of your automated builds.

Package sources could be considered as upstream repositories for your MyGet feed, which is how you can look at the VSO Build Drop Location. The following simplified diagram provides a schematic overview of this new integration scenario.


All you need to do to make us of this integration is to add a new package source to your MyGet feed:

  1. Go to your feed's settings and select the Package Sources tab. Select Visual Studio Online build definition from the Add package source button.

  2. Provide your Visual Studio Online account name in the dialog that appears and click Continue.

  3. Select the Team Project and Build Definition to add as the package source for your feed. Optionally, select the Team Room in which to post notifications. Click the Add button to complete the configuration of the new package source.

  4. The new VSO package source has been added to your feed's package sources, and newly built NuGet packages will be fetched from your Drop Location automatically and pushed to the MyGet feed.

New Scenario: Add a VSO Git repository as a Build Source for a MyGet feed

This is the same scenario we already support today for GitHub, BitBucket and Codeplex: you can now register MyGet Build Services as a post-commit hook to your VSO Git repositories. We are happy to provide an integrated VSO experience from within MyGet, but even happier to also have a MyGet service hook available within the VSO user interface! Whether you use the VSO user interface or MyGet web site, you can enable this scenario from within both.

Build sources are a way to express links between MyGet Build Services and your source repositories, whether on GitHub, BitBucket, Codeplex or now also on Visual Studio Online. The following simplified diagram provides a schematic overview of this new integration scenario.

Note: we currently only support Git repositories, TFVC support is on the roadmap.


Here's a step-by-step guide on how to register a VSO Git repository within MyGet Build Services.

  1. Go to your feed's settings and select the Build Services tab. Select from Visual Studio Online (git only) from the Add build source… button.

  2. Provide your Visual Studio Online account name in the dialog that appears and click Continue.

  3. Select the desired build source to link and optionally enable notifications in a specific Team Room. Click the Add button to complete the configuration of the new Build Source.

  4. The new VSO build source has been added to your feed's build sources, and a post-commit service hook has been registered within VSO. When pushing to your VSO Git repository, a new MyGet build is going to be triggered and will produce your NuGet packages and push them to your feed.

    If you look at your Visual Studio Online Administration dashboard and browse your Team Project's Service Hooks, you'll see a newly registered web hook listening for the Code is pushed event.

New Scenario: Connect an existing MyGet Build Source to Visual Studio Online

Alternatively, you can also setup MyGet integration from within Visual Studio Online. This is useful if you already have an existing MyGet Build Source pointing to your VSO Git repository and triggered it manually up until now. You should be glad to hear you can now connect these and automate that.

  1. Go to your VSO Team Project Administration dashboard and select the Service Hooks tab.
  2. Click the Add Service Hook button

  3. Within the New Service Hooks Subscription dialog, select the MyGet service and click the Next button.

  4. Select the Code is pushed event type and the desired Repository and Branch settings. Click Next to continue.

  5. Select the Trigger a MyGet build action and provide the target Feed name and Build Source Identifier.

    You can find the Build Source identifier in your MyGet feed settings > Build Sources, as highlighted below:

  6. Click Test if you want to test this service hook first, or click Finish to complete the wizard. The new service hook is now listed as shown below:

We aim to please

We hope you are happy with this brand new VSO support and will put it to good use! We'd also like to express our gratitude to the Microsoft VSO team for enabling this type of extensibility as well as guiding us through this integration effort. A smooth, integrated user experience to reduce development friction is one of our main goals, and we hope these scenarios will prove to be a great help.

Feel free to send us your feedback or feature requests!

Happy packaging!

Picking the right dependency version adding packages from NuGet.org

Since NuGet 2.8, the NuGet Package Manager Console’s Install-Package command comes with support for specifying the dependency version resolution process using the –DependencyVersion switch. If you have never used it before, what it does is it allows you to specify how NuGet should resolve package dependencies. It can resolve dependencies to the lowest possible version (default behavior), the highest possible version, or the highest minor or patch version.

This feature is useful because it gives you control over how dependencies are resolved. For example, when package A has a dependency on package B >= 2.0 and available versions of package B are: 1.0, 2.1.1, 2.1.2, 2.2.1, 2.2.2, 3.0.1, 3.0.2, the version of package B that will be resolved will be:

  • 2.1.1, when DependencyVersion is Lowest
  • 2.1.2, when DependencyVersion is HighestPatch
  • 2.2.2, when DependencyVersion is HighestMinor
  • 3.0.2, when DependencyVersion is Highest
Word of warning: changing the default behaviour may break package dependencies. In theory, only the lowest defined version number is sure to work. If a dependency is specified for packages >=1.0.0, using DependencyVersion Highest would potentially bring in version 7.0.0 which may not work for the package depending on it. Use with caution!

If you are interested in always having the latest versions of a dependency within a given mayor version, the HighestMinor setting will actually do that. This can be done from the Visual Studio Package Manager Console:

NuGet select dependency version resolution strategy

This can also be set as a default for all NuGet packages installed by editing the NuGet.config file or using NuGet configuration inheritance:

<configuration> <config> <add key="DependencyVersion" value="HighestPatch" /> </config> </configuration>

When adding packages from an upstream feed like NuGet.org or a TeamCity server to a MyGet feed, this setting is available as well:

Specify DependencyVersion switch with MyGet

This should greatly help in getting your preferred packages installed instead of having to install and manually update dependency versions to the required version for your project. For more information about the DependencyVersion switch, do check the NuGet documentation.

Happy packaging!