MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Notifications let you know when a package is updated

Call it human nature, but whenever an update to a software package is available we want to know about it and install it immediately. We do this with our computer, phone and even our NuGet packages. For good reason! The packages we depend upon may be updated because of bug or security fixes and even new features we want to make use of.

MyGet already supported automatically updating NuGet packages from upstream package sources, however we felt that this might not always be the best solution for all scenarios. We’ve now made it possible to receive e-mail notifications about package updates instead, allowing you to decide manually if you want to upgrade or not.

Update notifications per e-mail

E-mail notifications can be enabled from your feed’s Package Sources settings, editing the upstream package source configuring which actions should be performed and when.

NuGet update notifications

We will send you an e-mail (or perform an automatic update, or both) at the chosen interval. This helps you keep up-to-date and allows for an easy update of the package: after clicking a link in the e-mail, MyGet will show what the latest available version is and offers a one-click install.

Latest available NuGet package version

Happy packaging!

Introducing MyGet webhooks

One of the most requested features for MyGet so far is support for webhooks. We’re happy to announce MyGet webhooks (preview) is available today. Every MyGet feed provides the option to communicate with external services, such as a web server, whenever a specific action occurs on the feed.

Webhooks for MyGet

Only feed owners and co-owners can manage webhooks for a feed. Each webhook can be triggered for one or more event types, depending on the implementation. Webhook deliveries can be inspected, including full logs, as well as redelivered in case this is needed.

Delivery log

Give webhooks at try! For more information, check our documentation website. We’re open for any feedback or feature requests you may have.

Happy packaging!

Configure a feed’s Report Abuse URL

Ever wondered where the “Report Abuse” link in Visual Studio navigated to? Or where it comes from?

Report Abuse URL

This link is available for every package, and on MyGet feeds, it will typically point to a dummy URL. The reason for that is it’s your feed, and you are the one who should respond to any messages that come in through it. But with a dummy URL, that obviously does not work… So we made it configurable! From your feed’s Package Settings tab, simply enter the URL Visual Studio should navigate to when clicked.

Configure Report Abuse link

This should make it easier to gather feedback on packages hosted on your feed.

Happy packaging!

MyGet now offered through the Microsoft Azure Store

Microsoft Azure

We are happy to announce that MyGet partnered with Microsoft to be included in the Microsoft Azure Store. This is our second partnership with them, since we also integrate with Visual Studio Online. The Microsoft Azure Cloud is widely used to build and deliver applications to end-users. Developing these applications could greatly benefit from using a package management solution to streamline development, and that’s where MyGet comes in.

Having MyGet available in the Microsoft Azure Store allows developers and team leads to create MyGet accounts for themselves or their team members, whether free or one of the paid plans. There are no separate bills to be paid: MyGet will be part of the monthly account statement or Enterprise Agreement.

imageIf you are a Microsoft Azure customer, here’s how to create a new MyGet account:

  1. Go to the Microsoft Azure Management Portal
  2. In the bottom toolbar, click New and select Store
  3. In the Choose an Add-on dialog, select MyGet and click next
  4. In the Personalize Add-on dialog select the MyGet plan you want to sign up for.
  5. If you want to create one (or more) paid subscriptions, you can use the promotional code STORELAUNCH, which will give you a 25% discount during the first 6 months of the subscription (code valid until end of August, 2014).
  6. Once the subscription is created, click Manage in the bottom toolbar and pick the username and password you wish to use for your MyGet subscription.

If you are an existing MyGet user and would like to make use of the Microsoft Azure Store integrated billing, contact support and we will make it happen!

Happy packaging!

Promoting packages generated during build

We’ve supported the “Push upstream” workflow for quite a while now. This workflow allows you to promote packages from one feed to another, ideal when you are pushing prerelease packages on one feed and pushing them as stable packages to another feed after testing them.’

So far, it has been only possible to push individual packages upstream, or all “latest” packages. We realized this was painful for one scenario: if you’re usign Build Services, it may be handy to be able to push just the packages generated by a specific build. And that is exactly what we’ve added now!

Promoting packages generated duing build

When expanding a build’s packages, a new menu entry Push upstream…is now available to push the packages generated by a build to another feed. This should greatly improve usability for this scenario.

Happy packaging!

Package details now showing update notification

When you create a MyGet feed, chances are you want to keep the packages up to date. This can be done automatically by enabling auto-update on the package sources for your feed, but that is not always desired. Some people prefer updating individual packages manually, which makes perfect sense: only packages you approved will be available on the feed.

To help detecting package updates, we’re now showing a notification on the package details page whenever any of the configured upstreampackage sources has a newer version available. With just one click, we can update the package and its dependencies.

Package update notifications

Give it a try on your MyGet feed!

Happy packaging!

Creating a license report for your NuGet feed

When managing your dependencies using MyGet, it may be important to have a view on which licenses are used on your feeds and in your software projects. Which licenses are your NuGet packages using? Many teams would love to know which (open source) licenses are being used by their teams, so they can be inspected and managed. It feels good to finally tackle one of those items that have been on our backlog for almost two years: we now support this exact scenario!

Note: this feature is only available for paid subscriptions.

From your feed, a new Licenses tab should now be visible showing a report of all licenses used by packages on your feed.

NuGet license analysis report

The licenses overview gives you a chart that provides a quick view on licenses in use. The list underneath shows all different licenses used per package identifier. If a package changed license over time, it will be listed twice. To quickly filter the detailed list, simply click one of the colors in the chart: this will show just the packages that have the selected license applied.

Where does license information come from?

Whenever a package is uploaded to your feed, whether from an upstream package source or by using nuget push, MyGet will perform a license analysis on the package. The license is determined as follows:

  • If we’ve seen the package’s license URL before, we will assign the same license to the package that is being added.
  • If your feed contains a package with the same identifier, we’ll take that package’s license.
  • If we haven’t, we’ll download the license URL result and run a full-text analysis on it. We’ve been working on a unique scoring algorithm which compares the text with known OSI licenses out there.
  • If the score is too low, we assign the license “Unknown” to the package.

Can I change licenses for a package?

Absolutely! Whenever you have a package where the license analysis was incorrect, or you have a proprietary package which has a unique license name, it is possible to assign it to a package. From the package details page, you can inspect the package license as well as override it.

View individual package license

Editing the license will open a dialog in which you can edit the license. We’ll provide autocompletion on known OSI licenses, but if you have a proprietary license name that can be entered here as well. Once a license has been overriden, new versions of the package will be assigned the overriden license.

Override NuGet package license

We’re eager to hear your feedback on this feature!

Happy packaging!

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!