MyGet Blog

Package management made easier!


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!