MyGet Blog

Package management made easier!


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:


  • Meta package, installing My.Framework and all localized satellite packages
  • Depends on: all satellite packages (,, My.Framework.Core.el, ...)
  • 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 :))
  • 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!

Introducing debugging, source code and symbols for NuGet packages

Shortly after we launched MyGet, we teamed up with to provide support for .NET debugger symbols. Today, we’re happy to announce a second option: integrated MyGet symbols support! MyGet symbols support lets consumers of our NuGet packages step through the source code and integrate with Visual Studio and tools like WinDbg. Additionally, symbols and sources can be consumed from within MyGet as well.

Head over to our docs and learn how to get started with MyGet symbols support!


How do I get started?

Documentation is available that will help you get started with MyGet symbols very quickly. Symbols in .NET can be tricky sometimes, so if things don’t work out as expected we’ve also compiled a list of PDB troubleshooting tips.

To make things easy, the endpoint for pushing symbols packages is the same as that for your regular NuGet packages:<feedname>/api/v2/package. MyGet will determine the type of package and act accordingly. This makes pushing symbols packages from your build server, like TeamCity or Visual Studio Team Services similar to pushing regular NuGet packages.

Where do my symbols packages go when I use MyGet Build Services?

For new feeds, symbols packages are pushed to your MyGet feed by default. For existing feeds, symbols will be uploaded to SymbolSource (if this was enabled). From the build configuration, you can select where to push symbols packages.

What happens to the SymbolSource integration?

SymbolSource integration is still available. Our customers asked very loudly for integrated symbols support, so we’re delivering on that. We are still providing the option to use SymbolSource with your MyGet feeds. In fact, they have some great new features planned as well!

Head over to our docs and learn how to get started with MyGet symbols support!

Happy packaging! (and efficient debugging, of course)