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.