MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

MyGet 2017.1 Release Notes

As MyGet is a software-as-a-service leveraging a subscription model, we're transitioning our versioning scheme towards a format that is more understandable: YYYY.R. As such, these release notes comprise our first milestone of 2017, hence the version number 2017.1

The MyGet 2017.1 milestone was tagged on June 1st, 2017.

Highlights

MyGet again adds some new functionality to the service. The following are the major highlights of this milestone.

We've built a MyGet Credential Provider for Visual Studio 2017! This extension allows you to authenticate against your MyGet feeds using OAuth. Install it from the Visual Studio Gallery!

Install the MyGet Credential Provider for Visual Studio 2017!

We added Maven support, and welcome Java/Android developers to the MyGet family! (Announcement | Docs)

Getting started with Maven on MyGet!

We've built a web utility to help you learn and adopt Semantic Versioning: check out our MyGet SemVer Explorer!

MyGet SemVer Explorer

We've partnered with OSSIndex.net to check for potential package vulnerabilities on your MyGet feeds! (Announcement | Docs)

Check for potential package vulnerabilities on your MyGet feeds!

Features

MyGet (all plans)

The following applies to all MyGet plans:

  • NPM: added support for token authentication
  • NPM: added support for upstream token authentication, which now also supports Telerik's NPM registry as an upstream package source
  • NPM: added support for the fast search endpoint
  • NPM: added support for package deprecation
  • NPM: added support for package tagging
  • NPM: added support for dist-tag
  • NuGet: added support for NuGet's SemVer2 protocol, and added support for modifying build metadata on push upstream dialog
  • Maven: introduced support for Maven artifacts
  • Maven: introduced support for Android AAR artifacts
  • Symbols: added a toggle to support pushing symbols upstream as well
  • Symbols: when the upstream target feed is a MyGet feed, we automatically also push the symbols upstream
  • Usability: no longer show symbols packages separately on the Gallery's feed details view
  • Usability: minor modifications to the Gallery feed details UI to improve the user experience
  • Usability: added a download all button to the packages dropdown in build results view
  • Usability: hide pre-authenticated feed endpoints from Feed Details view when the feed is not a private feed
  • Usability: added a copy-to-clipboard button to the connection details popup on Gallery feeds
  • Security: we've built a MyGet Credential Provider for Visual Studio 2017! This extension allows you to authenticate against your MyGet feeds using OAuth.
  • Security: we've consolidated the login page: one page to rule them all!
  • Security: we no longer display access tokens (you can still copy them though)
  • Security: improved auditing
  • Security: added support for feed and privilege scopes to access tokens / api keys (in addition to expiration support which we already had)
  • Integrations: SymbolSource.org integration has been retired in favor of MyGet's own Symbols functionality
  • Integrations: added OSSIndex.net integration to detect package vulnerabilities and report them on your feed details view

MyGet Enterprise

The enterprise plan has all functionality from the paid subscription plans, and more! The following applies only to the MyGet Enterprise plan:

  • Usability: the Gallery index is now the default landing page when authenticated on MyGet Enterprise
  • Security: added support for marking users as external to the tenant. This prevents the external user from accessing Enterprise feeds, unless privileges are explicitly assigned at the feed level. (see Feed Types)

MyGet Build Services

  • Added support for Visual Studio 2017.NET Core and the new PackageReference project format (Announcement)
  • AssemblyInfo patching now supports globbing patterns (like **\**.cs)

Bug Fixes & Other Improvements

  • MyGet has been upgraded to run on .NET Framework 4.6.2, which seemed to have positive effect on performance
  • Overwriting source symbols is now blocked when forbid overwrite is enabled on the feed
  • Fixed a bug in semantic version range parsing of npm dependencies (tilde and carret ranges)
  • Show quota per feed on user profile page (helps answer the question: 'which of my feeds consumes most?')
  • Fixed an issue caused by breaking changes in VSTS API (repository remoteUrl returned by VSTS API no longer contained VSTS collection name)
  • Fixed an issue in the Gallery index view related to feed icons
  • Fixed an issue that caused an HTTP 500 when a nuspec contained some invalid data
  • Fixed an issue that caused NPM push upstream to fail when no package description was given
  • Fixed an issue with the symbols code browser when a file was not found or could not be displayed
  • NuGet: allow packages.config files to be uploaded without version number specified

Please tell us how we're doing by taking 10 seconds of your time to answer a single question (and optionally provide any feedback you want). We love hearing from you, so keep that feedback coming! MyGet is built for you!

Happy packaging!

Host your packages on MyGet!

Working with MyGet upstream sources

Upstream sources play a key role in a professional approach towards Package Management. MyGet gives you the option to specify one or more upstream sources for a package feed. Even though this feature has been available on MyGet for years now, we feel it upstream sources deserve a place in the spotlight once: they enable various scenarios that are impossible on any other package management service, and above all: they are a huge facilitator for a smooth and automated development workflow (and thus developer happiness :-)).

In this post:

  • Why upstream sources?
  • Supported upstream sources

Why use upstream sources?

In bullet-form:

  • Upstream sources make it very easy to pull in packages from other package sources onto your downstream MyGet feeds.
  • You can also target these upstream sources to push packages upstream from your MyGet feeds.
  • Any configured upstream source on your MyGet feed will be made available to you in MyGet Build Services, without having to commit any secrets such as credentials or API keys in your source repository. If you're using NuGet: no need to create a nuget.config file!

If you are confused about the usage of "upstream" and "downstream" in the context of package sources, we've got a little poetic explanation for you, which may already help you visualize the relationship between package consumers, your MyGet feeds, and your feed's upstream sources.

Consider the direction in which packages are flowing from a given package source to an ocean of consumers.Your package may have dependencies "upstream", to packages on another feed. From the point of view of those dependencies, the depending package is located "downstream". When a user consumes the downstream package, it will also fetch the upstream dependencies.The consumer, however, is only allowed to fetch or query those upstream packages if the feed being queried (downstream) is also configured to proxy (or mirror) the upstream package source.


Supported upstream sources

By default, MyGet feeds have the public, central repositories configured for each package type. This includes:

  • NuGet: https://www.nuget.org/api/v2
  • Bower: https://bower.herokuapp.com
  • npm: http://registry.npmjs.org
  • Maven: https://repo1.maven.org/maven2

To configure an additional upstream source for your MyGet feed, navigate to Feed Settings > Upstream Sources. Then click Add Upstream Source and select the package source type you want to add.

A dialog will prompt your for upstream source information and will also expose a few common presets for you to take advantage of. Did you know we even support Dropbox?!

Upstream Source Credentials

If you have any access privileges to other MyGet feeds, you will see those in the MyGet Feeds presets, so you can easily build a chain of package sources to facilitate a package promotion flow.

If you select a private MyGet feed you have access to as an upstream source, there's no need to provide credentials to be able to restore packages from it on MyGet Build Services. MyGet will impersonate your user account when authenticating against that upstream source.

For any non-MyGet upstream source that requires authentication to pull packages, you'll have to provide username and password to be used during Basic Authentication.

Warning! Be very careful with password managers and browser add-ons providing auto-completion of credentials!
We recommend disabling these credential managers on the MyGet web site to avoid issues when editing upstream sources. Oftentimes, these tools auto-complete the credentials fields with out-dated credentials (even when editing different settings in the dialog). 
When running into package restore failures on MyGet Build Services, or when noticing that upstream packages are no longer available downstream, this is the most common source of the issue.

In the opposite direction, in order to push packages from your downstream MyGet feed to the upstream source, you may need to configure a (scoped) API key or access token.

Package Source Filtering

Applies to: NuGet (v2 only!)

When the upstream source is a v2 NuGet feed, you may configure additional OData filtering. Filtering is based on the OData v3 Filtering System. Valid filters are similar to Id eq 'jQuery' or IsLatestVersion eq true and Id ne 'Foo'.

Warning! This capability may go away at some point in favor of newer NuGet v3 APIs.
We currently still keep the feature around for some scenarios that are not yet fully supported on NuGet v3.

Adding a package from an upstream source

You can easily add packages to your MyGet feed originating from an upstream source, such as nuget.org, nmpjs.org, etc. This is using the feed's configured upstream sources under the hood. If you want to add a package from another feed onto your MyGet feed, the other feed needs to be configured as an upstream source to that feed.

Adding a package from an upstream source can happen in three ways: manually, by reference (proxying), or by value (mirroring).

  • Manually: you can add packages from an upstream source to your feed manually by using the Add Package button you will find under your feed's Packages page.

Select From Feed in the dialog that prompts.

  • Proxying: the package metadata is copied to the MyGet feed, the package itself remains hosted on the upstream source. When querying the package, we call the upstream source to fetch the package.
  • Mirroring: the package metadata and the package itself are copied onto the MyGet feed. When querying the package, we server the package directly and don't use the upstream source. Mirroring of a package version happens upon the first request for that given package version.

Configuring upstream sources on your MyGet feed unlocks quite a few integration scenarios and automation opportunities!

Proxy packages from an upstream source

You can configure an upstream source to proxy upstream packages through your MyGet feed to your feed consumers. Proxying makes it easy to have a single MyGet feed aggregate packages from multiple sources. Package consumers need only to configure a single MyGet feed, and all packages available on upstream, proxied package sources will become available to them.

Benefits:

  • upstream packages do not count against your MyGet storage quota
  • authentication against upstream, private MyGet sources happens automatically (see Upstream Source Credentials)
  • especially for NuGet: no longer subject to chatty clients reaching out to all configured feeds during dependency resolution (MyGet can be smarter server-side)

Drawbacks:

  • every package request will incur additional latency as opposed to storing the package onto the MyGet feed

Warning! Avoid configuring multiple package source proxies on a single feed, or in a chain of feeds, as this will magnify the disadvantages, and result in very slow feed response times.

The following diagram illustrates the effects of upstream source proxying.

To enable upstream source proxying, you must tick the check-mark next to Make all upstream packages available in clients.

Mirror packages from an upstream source

You can configure an upstream source to mirror upstream packages onto your MyGet feed. This configuration is similar to package proxying, but takes it one step further.

Whenever someone requests a particular package from your MyGet feed for the first time, MyGet will query the upstream source and copy the package onto the MyGet feed.

Benefits:

  • No additional latency (except for the first hit that triggers the package mirroring)
  • Protected against upstream source availability issues
  • Protected against upstream package removal
  • Authentication against upstream, private MyGet feeds happens automatically (see Upstream Source Credentials)
  • Faster builds!

Drawbacks:

  • Mirrored packages count towards your MyGet storage quota (a classic storage versus speed trade-off, you can always upgrade your subscription or request a quote!)

The following diagram illustrates the effects of upstream source mirroring.

To enable upstream source mirroring, you must tick the check-mark next to Automatically add downloaded upstream packages to the current feed (mirror).

Optionally, you can also tick the third check-mark to indicate that any package found upstream is to be considered a package dependency (and should not be consumed directly). This will hide those packages from search results, whilst still allowing you to restore them.

Once upstream source mirroring is enabled, we can consume our MyGet feed from Visual Studio which will also list upstream packages. For example, the example acmecompany feed only lists one package:

One package on our feed

When searching in Visual Studio, we do see packages that originate from upstream sources:

Visual Studio showing upstream packages

After installing this package, our feed now automatically contains a copy of the jQuery package:

Mirror upstream pckages

From now on, the package is available from our MyGet feed directly, without having to explicitly add it manually from the upstream source.

Using a MyGet feed as a staging area (before pushing upstream)

Many development teams are using some kind of package promotion workflow: pushing a package from one feed to another based on quality gates, target audience, or any other criteria. This is very typical scenario for which upstream sources are essential.

Of course, all of this can happen in an automated fashion using package manager client. However, as promoting a package typically involves some kind of human intervention (e.g. release manager approval), we've also made it a first-class feature in the MyGet web site.

Simply pick the package version you want to promote from the package details page, and hit the Push button to initiate the package promotion flow.

A dialog will provide you with additional options. MyGet is also smart enough to detect any package dependencies you might want to push along in one go as part of this package promotion flow.

At this point, you can still make a few metadata changes before pushing upstream. This dialog allows you to:

  • modify or remove the prerelease label of the upstream package version. This allows you to e.g. drop the prerelease label to release a package without rebuilding/repackaging.
  • add release notes to be included in the package metadata. MyGet will even support release notes written in markdown and render them properly on the web site!
  • modify or remove the SemVer2 build metadata part of the upstream package version
  • exclude any detected dependencies or satellite packages from the push action
  • apply source labeling if the package was built using MyGet Build Services. When enabled, MyGet will find the build from which the package originated and will add a label to the source control revision it was built from.

To edit a package's metadata, simply click the Edit button next to it and make the modifications. To apply a given modification to all packages in the dialog, hit the rain drop button next to the editable field.

Using upstream sources on MyGet Build Services

Applies to: NuGet, npm

Upstream sources for a feed are also available during build. This can be useful in the following scenarios:

  • An additional upstream source is needed during build. MyGet will make the upstream source available during build if it has been added to the feed's upstream sources.
  • If you have a private feed requiring authentication but do not wish to add credentials to source control, credentials can be added to the feed's upstream source. These credentials will be available during build and allow you to consume a protected feed with ease.

Applies to: NuGet

  • The API key for an upstream source is also made available during the build process. This means during a build, you can call into nuget.exe push and push packages to configured upstream sources.
  • If you want to make use of nuget.exe push in a build script without having to specify the -Source parameter. This requires a default upstream source to be defined.

Applies to: npm
We strongly suggest to proxy registry.npmjs.org to be able to run `npm install` during build, as npm will default to the MyGet feed as the default registry.

Setting default upstream sources to be used on MyGet Build Services

Applies to: NuGet

The NuGet.config file on our build agents is configured using NuGet's defaults, enriched with all NuGet upstream sources configured for your MyGet feed. Based on these defaults, the following conventions are active:

  • The default upstream source is set to (Aggregate Source), meaning all feeds will be queried for packages in the order defined in the feed's upstream sources.
  • The default push source (when using nuget push without the -Source parameter) is NuGet.org.

Both of these conventions can be overridden by editing the build source configuration.

Auto updating packages

MyGet feeds can automatically fetch package updates made available through the upstream sources.

When adding or editing a upstream source, we can enable this behaviour per package source, as well as an interval when MyGet should check for updates.

Package Source Options

The following options are available:

  • E-mail me when package updates are available: Sends an e-mail to the specified recipient(s) when package updates are available on the upstream source.
  • Include prerelease versions: By default, MyGet will only consider stable packages. When enabled, we will also check pre-release packages from the upstream source.
  • Automatically update packages to their latest versions: Enables the behavior of automatically updating packages from the upstream source.
  • Update interval: Depending on your subscription plan, we can specify how often MyGet should check for updates (up to every 30 minutes on a Professional subscription)

As you can see, MyGet's support for upstream package sources unlocks a wide range of package management scenarios that may help you streamline your development flow and package governance even more. If you haven't tried the above scenarios yet, do give them a try and experience how it may make your life easier.

Oh, and we do support pushing your private symbols packages upstream along with your NuGet packages, too!

Happy Packaging!

PS: Please take 10 seconds of your precious time to tell us how we're doing

MyGet's NuGet and NPM news from the community (February 2017)

Here we are again with a new episode of MyGet's NuGet and NPM news from the community! We will look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

The .NET team announced .NET Core, .NET Native and NuGet Updates in VS 2017 RC. Quite a few changes, most notably the improvements in NuGet to use the new .csproj  format and package references therein. And early in February, NuGet 4.0 RC was released as well.

More news from Redmond: NuGet.org now also supports scoped API keys, just like we do. Where on MyGet scope is per feed, NuGet came up with a per-package model. Do check it out!

Will this be the new way of distributing project templates? As NuGet packages? Muhammad Rehan Saeed found a new element that can be used in a .nuspec  and demonstrates Custom Project Templates Using dotnet new.

Andrey Akinshin, a developer on JetBrains' Rider cross-platform .NET IDE wrote an in-depth article on how they are making the Rider NuGet client fast.

Puneet Ghanshani describes a way of creating an inventory of packages a solution uses by working with the NuGet.Core  package. Would be great to see something like this as a Visual Studio extension!

Scott Addie wrote a great article, Migration to ASP.NET Core, where he walks through the various considerations and strategies of migrating a .NET codebase to .NET Core. The article covers the various frameworks, targets, the portability analyzer, and more!

Just started looking at thedotnet command line tool? Steve Smith explains how to add a Nuget Package Using dotnet add.

Managing the life cycle of PowerShell module assets in your Azure Automation accounts can be challenging. Not anymore! Tao Yang explains how you can leverage MyGet to its full extent to make this tedious task a breeze and take full control of your very own PowerShell Gallery, on MyGet.

NPM news

A fresh npm@4.2.0 landed, featuring improved search - faster and more relevant. Debug logs are now saved in the _cache  folder, making it easier to clean them up.

Node.js itself also dropped a new version - v7.5.0. Ehm no, v7.6.0. Noteworthy changes are an update of openssl (1.0.2k), the ability to use system CA's (yes!) and a number of bugfixes.

NPM Vet is a new tool that allows us to to quickly visualise the difference between versions defined in our package.json  and versions installed in the node_modules  folder. In other words: it helps us check for dependency mismatches.

Happy packaging!

MyGet's NuGet and NPM news from the community (October 2016)

Here we are again! Our third installment of MyGet's NuGet and NPM news from the community. Each month, we bring you some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

NuGet news, curated by MyGetWondering what's happening with .NET Core tooling? Microsoft released a blog post with more background information on Visual Studio '15'. Looks like NuGet package references will become part of the project file.

.NET Core 1.1 Preview 1 was just released. It includes support for additional Linux distributions and has many updates, new middlewares and so on.

What's up with all these target frameworks in NuGet and .NET Core? Immo Landwerth sheds some light on NETStandard, discussing how it will solve the code sharing problem for .NET developers across all platforms.

Jeremy Miller wrote a war story converting a complicated codebase to CoreCLR.

Were you using NuGet.Core in your code? Try the new client libraries instead, with support for v3 feeds. Andrei Marukovich wrote a good introduction on the new client libraries that covers some basic operations.

Still learning NuGet? Erik Dietrich wrote a blog post "How To Put Your Favorite Source Code Goodies on NuGet" where he explains the simple process of taking a piece of code, packaging it up and publishing it out there.

On Emin Atac's blog: Inside the NuGet bootstraping process. He looks into PowerShellGet and how it initializes the NuGet PowerShell module provider and brings the required dependencies to our machine.

Filip W.'s proud of Elon Musk planning to go to Mars. Meanwhile, we get to experience this.

NPM news

NPM news, curated by MyGetA fresh version of npm landed, 3.10.9, mostly containing bug fixes in the shrinkwrap and uninstall commands. A pre-release of 4.0.1 also appeared, with some really nice changes in how search works (now streamign results instead of buffering).

Not ony a fresh npm, also a fresh Node.js! The team just baked version 7.0.0 with an updated V8 engine (5.4) which brings performance and reliability fixes.

Want to know how the folks at npm deploy? They just blogged about it. A git push is all it takes, at least on the surface. Quite a few tools and conventions are used under the hood to make that work smoothly.

Hello, Yarn! - Facebook announced a new JavaScript package manager which is fully compatible with NPM and introduces really good installation and resolution performance. We're keeping a close eye on this one!

A great series of blog posts on using Node.js at Scale - npm Best Practices has started. It is a series covering bigger Node.js installations, fordevelopers who already learned the basics of Node from writing clean code to deploying to monitoring.

Follow the leader! The folks at npmjs.com released some boiler plate code for following, replicating or doing other things based on newly uploaded packages. Pretty cool if you want to drink from the firehose!

If you have any news to share or have other feedback, let us know using the comments below or reach out on Twitter.

Happy packaging!

MyGet 2.2 Release Notes

MyGet 2.2 was released on August 19, 2016.

Highlights

This 2.2 release of MyGet again adds some new functionality to the service. Major highlights of this release are:

Features

MyGet (all plans)

The following applies to all MyGet plans:

MyGet (paid plans)

Obviously all paid plans also get the enhancements made available on the free plan. The following applies to the MyGet Starter and Professional plans:

  • Billing: new profile section providing access to your invoices
  • Billing: ability to configure a different email address for billing

MyGet Enterprise

The enterprise plan has all functionality from the paid subscription plans, and more! The following applies only to the MyGet Enterprise plan:

  • User management: we added support to block user registration so that an invite-only environment can be created
  • User management: we introduced a new Feed Creator role, allowing MyGet Enterprise administrators to delegate feed creation permissions to a non-administrator account

MyGet Build Services

  • Improved build log viewer with warning and error navigation, log level coloring and deep linking support
  • The build log now also recognizes Kiln source control: commit SHA now also has a hyperlink to Kiln source repository
  • Made performance optimizations to the Build Sources page


Bug Fixes & Other Improvements

  • NuGet: Preserve Chocolatey-specific additions to the NuGet package manifest (.nuspec) when pushing packages upstream
  • NuGet: Fixed an issue with NuGet packages that caused Summary metadata not to be populated properly when uploaded through the web site
  • NuGet: Fixed an issue causing failures when proxying Sonatype Nexus feeds on calls to GetUpdates() and Search()
  • Bower: now also detecting bower.json in subdirectories of uploaded bower packages
  • NPM: fixed an issue causing 404 errors when proxying upstream scoped packages
  • Usability: improved ordering of SemVer and non-SemVer package versions in the same feed
  • Usability: no longer allow 0 as value for package retention rules
  • Usability: when filtering package views, the Delete All button should not be visible to reduce potential confusion and avoid accidental deletes
  • Fixed an issue causing pushing to upstream package source to fail downloading the package from source feed on MyGet Enterprise with custom domain
  • Support Github-style code blocks in markdown

We love hearing from you, so keep that feedback coming! MyGet is built for you!

Happy packaging!

Keeping feeds clean with retention rules

MyGet Package Retention Rules help clean up your NuGet npm feedMany developer teams use MyGet for storing their continuous integration and/or nightly builds of NuGet, npm, Bower and VSIX packages. As more and more packages get added, it may become harder to manage them all. Some packages may be used in projects, while others are not. Let’s go over the options available for housekeeping.

By default, MyGet keeps all package versions available on our feeds. Every package pushed is there forever, unless manually removed or removed by package retention. By setting retention rules, it is possible to automatically trim the list of packages to X latest packages, keeping into account package usage in projects and package dependency trees.

Configuring retention rules

Retention rules are defined per feed. Some feeds may have more aggressive retention rules defined, other may not have them enabled at all. From the Retention Rules, we can define:

  • the maximum number of stable versions to keep
  • the maximum number of prerelease versions to keep
  • whether to keep depended packages or not – enabling this makes sure package restores always complete successfully by keeping the dependency tree in its entirety
  • whether to allow removal of packages that have downloads – enabling this option ensures that packages that are being used in projects never get deleted

Setting retention rules

Keeping a specific package around

Retention rules are quite brute-force: they will always remove all packages that match the configured rules. Luckily, MyGet lets us “pin” packages which we want to keep around. For example, we may want to only keep the latest 10 pre-release versions while still keeping around the 20th pre-release version we’re still using in our projects.

From the package details page, we can define which package versions should never be considered by retention rules by using the Pin button next to the package.

Pinning packages so they do not get removed

We can pin package per version, or all versions at once using the button at the top of the Package History list. Of course, we can also Unpin packages using the same approach. Once a package is unpinned, retention rules are allowed to remove them.

Custom retention rules using web hooks

Using the built-in retention rules may not be enough. For example, what if we want to run retention rules based on other conditions than the latest version? What if we want to only remove packages when there is a full moon? Using web hooks, we can subscribe to certain feed events (like “package added”) and run our custom logic to optionally remove packages from our feed. We have a complete example available that helps getting started with web hooks.

Learn more about package retention in our documentation.

Happy packaging!

MyGet by the numbers

As it is a slower time of year and many people are taking some vacation, we decided it would be a nice time to collect some numbers around MyGet. Of course we can’t share all of our statistics, but it’s always fun to look at them. MyGet has a shared tenant, www.myget.org, hosting and serving NuGet, npm, Bower and VSIX packages. And debugger symbols, of course. This shared tenant will be the focus of this post. Our MyGet Enterprise plans, which run on their own dedicated tenant infrastructure, are not included in these statistics.

Number of machines

Our web application is hosted on Microsoft Azure across three different regions. The shared tenant has its primary location in the West Europe region, and a secondary in US East. Both locations run 3 front-end web server machines and 2 back-end machines for handling anything that doesn’t have to happen real-time. These machines are all general purpose “A3” machines. We have a tertiary deployment in US West for some Enterprise customers, where a similar deployment lives.

Since we use auto-scaling based on time of day, we don’t have the same amount of machines throughout the day. On average, we run 10 machines for our front-end.

Another deployment lives in a private datacenter and hosts part of our build services. We also run our CI systems in this private datacenter. Azure is great, but also super expensive for some workloads. Hosting this workload ourselves reduces the operational cost for build services with a factor 6. This infrastructure is all SSD based, and we’re getting loads more horsepower out of the VM’s running here. To give an example: the Visual Studio 2015 Update 3 install ran for 4 hours on our Azure build agents, the private VM’s did the update in half an hour.

Number of packages and downloads

Our shared tenant currently hosts over 1 million unique packages. These packages have been downloaded 17,305,790,397 times so far. Yes, that’s over 17 billion. We handle roughly 400 million downloads each month. Some of our Enterprise customers are pushing similar numbers on their instances.

If we look at package types, roughly 50% of packages are NuGet and symbols packages, including Chocolatey and Octopus Deploy. 30% of packages are npm, with Bower and VSIX following at around 10% each.

Storage, traffic and bandwidth

Right now, our shared MyGet tenant consumes 3.2 TB of storage for just packages and metadata, including backups in secondary Azure regions.

Each month, users of www.myget.org push 2.4 TB of data into our system. Many feeds contain CI packages and retain only the latest 100 nightly builds. Other feeds contain 100 MB of Octopus Deploy artifacts, being updated daily. On the consumption side, we have 8 TB of traffic being consumed each month, spread across our Azure bill and the Switzerland-based KeyCDN.

We used to run off the Azure CDN, but found that KeyCDN has been more reliable at half the price. We still have the Azure CDN configured so we can fail-over in case it’s needed. So far, this hasn’t been required. Swiss efficiency #ftw!

Builds

When we first introduced build services, we envisioned making building NuGet (and later npm) packages as easy as possible. We have a number of open source projects running their builds on MyGet, as well as a number of companies enjoying the convention-based builds.

MyGet Build Services has produced over 65,000 successful builds (producing packages) so far. On average, these builds take 2 minutes to complete, with some people maxing out the 30 minute build time we allow.

Support requests

Ask any MyGet user and they will confirm we offer an excellent and speedy support. We typically manage to respond within the hour, unless we’re asleep. Which happens for a good 7 hours each day when night falls over the CET time zone. Our fastest response  so far providing a solution to the customer was 38 seconds.

We handle a good 45 support cases each day. Some of those are simple: we can often respond with a link to documentation. Others are more complicated and challenging. And if we can, we submit a PR to your project to resolve any code or configuration issues.

The busiest day of the week? Thursday. By far. It seems that is the day where everybody realizes the week is over halfway and things must be shipped. Unexpected to us, holidays are also quite busy. It seems many developers sneak in a few hours of coding time on those days and often want us to be part of that.

If we look at technologies, 80% of questions or client configuration problems are related to NuGet. 9% of requests are related to npm. And less than 1% for Bower and VSIX. What with the other 10%? These are typically orientation questions to see if MyGet is a good fit, or if MyGet fits in the customer’s architecture or development practice.

When we started this adventure, we never thought these numbers would become true. Thanks for making this happen and being a big part of this!

Happy packaging!

MyGet 2.1 Release Notes

MyGet 2.1 was released on February 12, 2016.

Highlights

This 2.1 release of MyGet again adds some new functionality to the service. Major highlights of this release are:

This means, from now on, you can now also use MyGet to host your symbols, publicly or secured.

MyGet 2.1 Highlights

Features

MyGet (all plans)

The following applies to all MyGet plans:

MyGet (paid plans)

Obviously all paid plans also get the enhancements made available on the free plan. The following applies to the MyGet Starter and Professional plans:

  • Security: Feed privilege claim tokens now expire after 15 days when unused
  • Billing: we now allow for yearly billing to reduce the administrative overhead of billing cycles

MyGet Enterprise

The enterprise plan has all functionality from the paid subscription plans, and more! The following applies only to the MyGet Enterprise plan:

  • Support for restricting feed creation to administrators only

MyGet Build Services

  • Support for explicitly publishing artifacts using service messages
  • Support for BitBucket API v2.0 and switch to OAuth 2.0
  • Support for xUnit v2.0
  • Support GitLab POST hooks
  • Performance improvements in build hook payload parsers
  • Web Hooks: new Build Queued web hook
  • New option: toggle access to build log for feed consumers

Bug Fixes

  • Various performance improvements in the web site
  • Bower: license analysis now also checks Bower package licenses
  • Usernames on feed security page now link to the user profile page
  • npm: proxy dist-tags from upstream when available
  • Fixed a bug where in some cases uploading a ZIP file Bower package threw an exception
  • Fixed a bug where in some cases pushing an npm package upstream to npmjs.com failed
  • Fixed a bug where editing a package source was not possible when the package source is unavailable

We love hearing from you, so keep that feedback coming! MyGet is built for you!

Happy packaging!

Adding another MyGet feed as a package source - Feed presets

Many people are using multiple MyGet feeds in their development flow, and have good reasons to do so. Some are pushing packages from one feed to another as they promote them through quality gates. Others are proxying upstream feeds or filtering packages downstream.

MyGet supports many types of package sources, and as flexibility is great, configuration can be a little tedious or even error prone.
Why would we ask our users to provide us with their MyGet feed url if we know what feeds the user collaborates on? We realized we could do better. In addition to the already rich list of presets, we have added a convenient button that lists your MyGet feeds.



It works the same way as the presets, and will populate your package source name and URL. This convenience helps avoid wasting time configuring your package management workflow and ensures the upstream feed is configured correctly.

Happy packaging!

PS: At MyGet, reducing friction is a feature. One that we consider most important! After all, that's how we have been able to deliver a smooth package management experience, serving over 16 billion package downloads over the past few years. Have a feature request or an enhancement you'd like to see? Please reach out to us!

Improved support for localized satellite NuGet packages

At MyGet, we live and breath a culture of componentization, and we are very happy to see package authors adopting and sharing these practices within their organizations. One of these practices is the usage of NuGet's localized NuGet packages feature. The adoption of localized satellite packages is a good indicator of package author maturity. Using a better practice should be rewarding and free of friction. One of our Dear Users provided us with great feedback on how he leveraged MyGet to release localized packages by pushing them upstream. However, some unnecessary friction was involved, which had to be removed.

Localized NuGet Packages

As a NuGet package author, you can provide a localized experience for your libraries. The NuGet client has supported the creation of localized satellite packages since version 1.8.

For those unfamiliar with the concept, here's a basic package graph demonstrating the idea:

My.Framework.1.0.0-alpha0001.nupkg

  • Meta package, installing My.Framework and all localized satellite packages
  • Depends on: all satellite packages (My.Framework.Core.nl, My.Framework.Core.fr, My.Framework.Core.el, ...)
My.Framework.Core.1.0.0-alpha0001.nupkg
  • Package containing an actual framework library (e.g. in lib/net45/My.Framework.Core.dll)
  • No dependencies for the sake of the demo (your libraries most likely have dependencies :))
My.Framework.Core.nl.1.0.0-alpha0001.nupkg
My.Framework.Core.fr.1.0.0-alpha0001.nupkg
My.Framework.Core.el.1.0.0-alpha0001.nupkg
  • 3 localized satellite packages for the My.Framework.Core package
  • Depends on the actual framework package being localized: My.Framework.Core.1.0.0-alpha0001.nupkg
  • Only contains localization resources (e.g. lib/net45/nl/My.Framework.Core.resources.dll, lib/net45/nl/My.Framework.Core.xml)
Or visualized in a graph, here's the dependency tree:


To facilitate discovery of these satellite packages, we added a convenient Localization tab on the package details page if localized satellite packages are detected.


Releasing localized NuGet packages

Ideally, releasing a package that has localized satellite packages from MyGet to another feed, should be a click of a button away, publishing the entire package-set at once. Optionally, one might also want to adjust the prerelease tag and release notes of this package set, either per package individually, or for all at once.

The Push Upstream feature (also check our docs) has been upgraded to now also detect package dependencies and localized satellite packages!

This means that, as in the above sample scenario, you can now publish the entire localized package-set in one go by pushing the My.Framework meta package upstream.


In addition, you can also edit (or simply remove!) the prerelease tag and/or release notes for each package individually, or for all of them at once!

Simply click the edit button  next to one of the packages, modify the fields, and click the water-drop icon  to apply the changes to all other packages in the dialog.


Of course, you can still exclude individual packages from this list if you want to by clicking the  button next to the respective package.

We love this kind of feedback and hope you find this change useful, so keep the feedback coming!

Happy Packaging!