MyGet Blog

Package management made easier!


Using a private MyGet feed with JetBrains Rider

image_thumb2JetBrains just released a new .NET IDE: Rider. At MyGet, we’ve been using Rider for our internal development since it was announced. So far, we have really enjoyed this IDE built around ReSharper! And since it comes with a lightning-fast NuGet client, let’s see how we can consume packages from a MyGet feed.

Adding a MyGet feed package source

The first step in connecting Rider to a MyGet feed is adding it as a package source. We can do this using NuGet.exe (via good old NuGet.config), or from within Rider. From the NuGet tool window, open the Sources tab. This will show us all of the NuGet configuration files that are in play, and a list of all feeds configured.


From here, we can add our MyGet feed (or edit an existing entry). We will have to give our feed a name so we can easily recognize it in Rider, and the URL to our feed. This URL can be found on the MyGet feed details page after logging in to


The NuGet client in Rider supports working with public and private MyGet feeds. While Rider supports using pre-authenticated feeds as well as feeds that require entering credentials, we recommend using the latter. Rider safely stores our MyGet username/password in its password store, which is based on KeePass.

Using MyGet together with JetBrains Rider makes it possible to develop .NET applications and let your development team consume both public and private packages hosted securely on MyGet.

Happy packaging!

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

Another month, another episode of MyGet's NuGet and NPM news from the community! We'll 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!

Note that this will be the last episode of our monthly news for now. Let us know if you'd like to see this series continue!

NuGet news

The NuGet team is considering improving package identity and trust by allowing to verify accounts and reserve package prefixes. For example, System.* could be reserved for the .NET Foundation so consumers always know the package comes from a thrustworthy source. Good read, good thoughts!

Naeem Khedarun built a tool that scans of outdated packages. NuGetXray, as the tool is called, helps identify outdated packages and can visualize this in a nice report (which can be included in a TeamCity build).

More tools! Maarten blogged about extending .NET CLI with custom tools, with an example tool dotnet init that initializes your NuGet package metadata.

MORE TOOLS! Alistair Chapman is introducing the Cake Build Systems Module which gives CI superpowers. For example on MyGet Build Services it will use service messages to add additional tracing to the build log. On TeamCity, the currently running build task is displayed. And more - give it a go!

NPM news

A GitHub PR was opened, discussing npm@5 and what will be included. Work in progress!

Axel Rauschmayer blogged about setting up multiplatform npm packages. In an example, he describes creating a package that targets ES5+, ES6 and webpack at the same time. 

Happy packaging!

How Stackify uses MyGet to manage their .NET dependencies and their product

We love developer stories! The folks at Stackify - who build, among other things, a free .NET Profiler, Prefix - wanted to share why and how they use MyGet to solve their .NET dependency management. Next to using MyGet for dependency management, they also share their nightly builds with customers and key users to be able to gather early product feedback. We'll let Matt Watson tell the story:

As a Microsoft developer, I was excited for .NET to solve the nightmares of dll hell. It did… but has since created a new problem: package hell. MyGet helps solve some of the challenges of NuGet. MyGet has been a big help for my team and can probably help yours, too!

At Stackify, we use MyGet for a few different reasons, which we will cover in this post. You may have heard of us via our awesome & free .NET Profiler, Prefix, or our APM solution, Retrace.

Pre-Release Packages

We started playing with .NET Core when it was in the early betas. At that time, the only way to get the latest versions of .NET Core nuget packages was via the MyGet package feed. Things were rapidly changing and we were constantly trying to keep up with what the .NET community was releasing.

As you can imagine, Microsoft does not ship daily builds of every .NET framework library to NuGet for everyone to access. They only release thoroughly tested and reviewed updates.

Between those updates they can use MyGet to get pre-release versions to their beta testers. They could publish pre-release versions to NuGet, and sometimes they do.

Publishing pre-release version to NuGet also broadens who has access to the packages. By putting them on MyGet, it keeps the casual developer from downloading beta versions and having lots of problems.

MyGet is a great solution for publishing daily builds of your packages. You can then tell your power users how to access them.

At Stackify, we can do the same sort of process to internally test new versions of our packages before we give them to our clients or air our dirty laundry on NuGet.

Hosting Internal Private Packages

At Stackify, we have several projects that are shared across multiple applications. We have elected to split out some of these projects in their own source code repositories. It helps us keep our repo size(s) down and also helps enforce some good practices around changing shared dependencies.

NuGet packages are the preferred way to share those class libraries across applications. Since the code is for internal purposes, MyGet’s private package feeds are a great solution for us. It provides a secure way to use NuGet packages.

We created a build and deployment process up in our Bamboo build server for the projects. After we check in our code, we manually kick off a build and it will take care of building the code and publishing a new package to MyGet for us.

After the shared packages are updated on MyGet, we can update the applications that use those shared packages.

Publishing NuGet Packages with Debug Symbols

One of our applications requires that we use tools like WinDbg to regularly analyze crash dumps. To do this, we need the debug symbols from our projects.

For security reasons, we don’t ship our debug symbols anywhere. Trying to keep track of the matching debug symbols for every version of our class library is a nightmare.

We solved this problem by always publishing a package that includes the debug symbols to our private MyGet package feed. Now anytime we need to use WinDbg, we can point our symbol source at MyGet and WinDbg automatically retrieves the debug symbols from MyGet. It is almost magical!

This also works well for debugging the libraries we have pulled out into their own repos as shared dependencies. It allows developers to test their package but still step through the code.

Thanks for the story, Matt! Make sure to check out both Stackify and MyGet!

Guest post by Matt Watson. Matt is the Founder & CEO of Stackify. He has been a developer/hacker for over 15 years and loves solving hard problems with code. While working in IT management he realized how much of his time was wasted trying to put out production fires without the right tools. He founded Stackify in 2012 to create an easy to use set of tools for developers.

Consuming packages from MyGet with Yarn

A while back, Facebook released Yarn – an open-source alternative for Node’s npm package manager. It’s a new client for working with npm packages, with a focus on performance and reliability. There are quite some blog posts out there benchmarking the npm and Yarn clients, but generally an install is somewhere between 9% and 50% faster with Yarn. Let’s see how we can use Yarn with a feed on MyGet!

Consuming packages

Assuming we have already created a feed on MyGet that contains a few packages, let’s first setup Yarn to use that feed as its registry. This can be done using the yarn config command:

yarn config set strict-ssl false
yarn config set registry ""

We can also keep the default registry and only configure Yarn for our own scope, so that only our own packages are downloaded from MyGet. No problem, let's set the @acme scope's registry to our MyGet feed:

yarn config set @acme:registry ""

The settings are stored in our user profile folder in the .yarnrc file. Just like with npm, the .yarnrc file (and even .npmrc) can be copied into our current project's folder so that settings only apply for that project and not for all comands we execute with Yarn.

Once we have configured our MyGet feed as the registry, we can install packages using Yarn quite easily using the yarn add <packagename> command (which will add the package to our package.json as well). If a package.json already lists dependencies, we can run yarn install as well to fetch all dependencies.

yarn add bootstrap@3.3.7
Do note that for private feeds, the pre-authenticated feed URL has to be used. Yarn does not support private packages out of the box, and a pre-authenticated feed URL is a secure workaround.

Publishing packages

Unfortunately, publishing is not a smooth ride yet. The yarn publish command is able to prompt for credentials succesfully (username, e-mail and password), but after that it seems to hang. Feel free to try it out and post your findings on this GitHub issue.

No problem though: we can still use our good friend npm to handle package publishing.

Happy packaging!

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

Here's a fresh episode of MyGet's NuGet and NPM news from the community! Like each month, we'll 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

Let's start with the big one: Visual Studio 2017 has been released. A new IDE with a revamped project system (bye project.json), .NET Core tooling and more. Oh, and a fresh NuGet.exe 4.0.

Sean Feldman shares a great blog post about leveraging MyGet web hooks and Azure Functions for sending out notifications.

In VSIX Continuous Delivery using Cake, AppVeyor and MyGet (do make sure to read the entire series), Alistair Chapman covers setting up a CI/CD pipeline using best-of-breed tools.

Steve Desmond released a new tool called LibYear. It is an addon to dotnet.exe  and scans a project for outdated package references. It also features an update  command to update all referenced dependencies in one go.

NuGet Package Explorer is now a Windows Store application.

Just like ReSharper has been doing since forever, Visual Studio 2017 now suggests installing NuGet packages for missing types.

The .NET Core folks started an announcement repository to which you can subscribe to be notified of announcements and changes in .NET Core.

Matt Warren wrote a post with pointers to the .NET Core internals source code. Great list of resources if you want to dive deep into the new .NET.

Ivan Gavryliuk posted NuGet Versioning Hell. Not a rant, but a post on the importance of proper versioning.

NPM news

In the 4.3 branch, NPM released v4.3.3. A fresh NPM version v4.4.1 has landed! Nothing special though, just making sure all NodeJS versions are supported. There is also v4.4.2, bringing along a number of bugfixes. And v4.4.3. And v4.4.4. Or maybe just install the latest v4.5.0.

NPM has an RFC open related to file type dependency specifiers. It makes depending on files inside of our package.json 's dependencies easier. It can point to a package on disk, either compressed or extracted.

Nihar Sawant wrote a post on developing an interactive command line application using Node.He uses the commander  package to build a sample application, which is pretty nifty and handles the async and promises nature of Node in an easy to read manner.

Happy packaging!

Visual Studio 2017 and .NET Core support on MyGet

With MyGet build services, we can link a GitHub or BitBucket repository to MyGet and create packages automatically. Today, we're happy to release support for the new project format that was introduced with Visual Studio 2017 last week. With this support also came the latest SDK's, F# 4.1 support, a new NPM version and many more enhancements to our build services.

Building .NET Core NuGet pacages

Ever since the first release of "project K", we have supported building what became .NET Core projects. Some scripting was required to build a NuGet package from a project.json file though. With the introduction of Visual Studio 2017 and NuGet 4.0, building NuGet packages for .NET Core projects has become very easy.

NuGet has become a part of the MSBuild pipeline, which means just building a project with the correct flags enabled will result in a NuGet package being created. Let's see how

From any .NET Core project (in the new .csproj format)'s settings, we can navigate to the Package tab and enable Generate NuGet package on build. That's... it! We can add some package metadata, publish our source code to GitHub, and have MyGet build it for us.

By default, no debugger symbols package will be generated that can help consumers of our NuGet package to step into our source code. It's simple enough to enable this feature though. From the solution explorer, use the Edit ProjectName.csproj context menu and add two MSBuild properties: IncludeSymbols and IncludeSource.

<Project SDK="Microsoft.NET.Sdk">

<Authors>Maarten Balliauw</Authors>
<Description>Hello World for .NET Core.</Description> <Copyright>Maarten Balliauw</Copyright> <PackageTags>hello world core</PackageTags>

</PropertyGroup> </Project

Commit, push, and let MyGet handle the build and serve up debugger symbols.

Happy packaging! (and building)

MyGet webhook for Microsoft Teams / Office 365 Groups

It's been possible for a while to let MyGet notify external services through webhooks whenever an event happens on our feeds, such as a package added/deleted. Today, we've added support for Microsoft Teams / Office 365 Groups. We can use it to have MyGet post events to a Microsoft Teams room or Office 365 group - increasing visibility of changes on the MyGet feed with members of our team.

How to configure?

To configure a MyGet webhook for Microsoft Teams / Office 365 Groups, head over to the team (or group) and configure a new Incoming Webhook connector. The name can be anything we want, and the icon, too. A nice square MyGet logo is available from our media repository. Once we save the webhook, we can copy its URL - we'll need this one on the MyGet side of things!

In MyGet, we can add a new Microsoft Teams webhook under the feed's Web hooks tab. All we need to do here is paste the URL we just copied from the Microsoft Teams / Office 365 side, pick the events we're interested in, and click Add.

From now on, when one of the selected events happen in MyGet, we will get notified of this.

Happy packaging!

Maven packages just arrived on MyGet

Let's go straight to the meat: we just shipped Maven support! If you're packaging .jar and .war (or Android .aar) and have a pom.xml to go with them, you can now add these to your MyGet feeds (or should we start calling them repositories).

Maven support is enabled on all MyGet accounts - starting today, you access to the Maven features described in our documentation.

Which features are available?

We currently support almost all features we have available for other package managers: uploading your own packages (via the web UI as well as via mvn or Gradle) and adding packages from upstream repositories like Maven Central. Packages can then be consumed in IntelliJ IDEA or Eclipse, using Maven or Gradle. It's possible to proxy upstream repositories into your MyGet feed. You can manage permissions and users, inspect package licenses and vulnerabilities, ...

A Maven repository on MyGet can also be used as a staging area: packages and snapshots can be published on MyGet, and once they are stable, pushed upstream to another repository out there - similar to what is possible for NuGet and NPM.

We're looking into supporting build services as well (theoretically you can already create a build.bat and invoke `mvn deploy` from it), but we'd love your feedback on what the perfect convention-based build for Maven/Gradle would look like.

Awesome! How do I get started?

Quite easy: head over to, sign in (or register) and create a feed. Our getting started documentation has some more details on how to upload your first Maven package to MyGet.

We're really excited about introducing Maven support on MyGet! You can now use MyGet to securely host and collaborate on NuGet, symbols and sources, Chocolatey, PowerShell, NPM, Bower, Maven and VSIX packages.

Happy packaging!

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

Happy 2017! We hope you had some good holidays and are now enjoying the world of NuGet and NPM again. In this 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

NuGet news, curated by MyGetThe NuGet team did another update of their documentation. They have now merged with Makes sense, with NuGet being such a big part of .NET development.

Support for Windows XP in NuGet is ending on April 8, 2017.

In NuGet, Dependency Management & a single point of package truth, Bobby Johnson published an interesting technique of consolidating all packages folders into one location, making NuGet consume less disk space and avoiding assembly reference conflicts where possible.

Oren Novotny is Multi-targeting the world: a single project to rule them all. His post talks about how you can now use a single project to build platform-specific libraries for all project types with Visual Studio 2017.

Jereme Evans walks us through How to create a NuGet package, set up CI, and other fancy things. The post describes how to create a project with source code on GitHub, using continuous integration on MyGet, publishing to

Dropcraft is a new NuGet-based app deployment and composition framework. In short, it allows running a simple command, download and extract a NuGet package. The downloaded package can be an app, or a plugin to an app, and composed at runtime.

Steve Smith shares how to re-install packages - useful to help VS in fixing any NuGet references that may be broken.

The new .NET Core tools will be based on Visual Studio project files, so time to change back from project.json to *.csproj. Nate McMaster blogs on how to migrate project.json to csproj and provides snippets on how to do things like multi-targetting, setting metadata, ...

NPM news

NPM news, curated by MyGetNode v6.9.3 (LTS) was released, a well as a brand new v7.4.0.

And a fresh npm@4.1.2 landed as well, with package.json symlink support, updated dependencies, and some additional test coverage.

Brett Nelson continues his blog post series on NPM scripts. In Getting Started with NPM Scripts - Delete Things!, he demonstrates adding custom npm commands (scripts) to perform cleanup steps which many people would use Grunt/Gulp/... for. The scripts approach seems much cleaner and straightforward!

In A way to manage nodejs and npm on windows, Dominique St-Amand explains how to update npm on Windows to the latest version in an easy way. Much better than the horror it is to run npm update -g npm!

Happy packaging!

Configure which feed a token can push packages to - introducing feed-scoped access tokens

Many development teams are making use of a continuous integration server like TeamCity, Jenkins or VSTS to build their projects and push generated NuGet, npm, Bower and VSIX packages to their MyGet feed. When having multiple feeds, it is a good practice to limit the feeds this access token/API key can push packages to, ensuring the surface area of the specific access token is limited to just the feeds the access token requires access to.

In short, scoped access tokens:

  • Are a good security best-practice: use minimum required permissions for a specific operation
  • Avoid services/users accidentally pushing packages by using read-only tokens where possible
  • Allow pushing packages without the ability to get access to other packages on the feed (write-only)

New access tokens and existing access tokens can be scoped in terms of what they can do. We now let you to create read-only or write-only access tokens, optionally limiting write access to just one specific feed.

Create new access token scoped to a given feed

Next to scopes, the access token expiration date and time can also be specified, making it possible to create a time-limited access token that has to be recreated to continue having access to the feed.

Happy packaging!