user

Package Consumers: Where are Packages Actually Used?

Introduction

Crista Perlton

Crista Perlton


LATEST POSTS

How Licenses Work with Chocolately 22nd March, 2024

How to Handle npm Dependencies with Lock Files 16th January, 2024

Inedo

Package Consumers: Where are Packages Actually Used?

Posted on .

As a package author, ProGet 5.3‘s package consumers feature gives you invaluable insight into which specific applications or component versions are consuming specific versions of your package. If you discover a critical bug or security vulnerability, you can identify the consumers and fix them or notify the responsible parties in as little as a few minutes. No more manual searches for consumers and nasty surprises when you realize you missed one.

Why does this help you? Packages are built off one another, with the resulting tangled mess often dubbed “Dependency Hell.”

Dependency Hell

Developer library packages (e.g., NuGet, npm, Pypi, etc.) are often built using other packages, which is noted as a “dependency” in that package’s manifest file. For example, the popular Moq library has a dependency on the Castle.Core library, and hundreds of other packages take dependencies on both of those.

These dependencies allow tools like Visual Studio to simplify package consumption when you build your own applications and components. For example, if used Castle.Core in your application but then later added Moq, you could potentially end up with two different, conflicting versions of the Castle.Core: the version that you’re using and the version that Moq requires. This is solved with “version ranges,” and library authors will typically specify a wide range of versions when defining dependencies. For example, the Moq 4.8.0 package will work with any version of Castle.Core that’s greater than 4.2.1.

But things get quite a lot more complicated in the real world. Modern applications are often built with dozens (or even hundreds) of libraries, and each of those can be built with any number of libraries themselves. Resolving all of the versions across all of the dependencies is not trivial (for example, see Microsoft’s NuGet Package Dependency Documentation), and the results are often different, depending on what library packages are available at any given time. This means, the actual libraries — which make up the bulk of the shipped code in any given application — may change by simply rebuilding the application; even if you don’t change a single line of your own code.

Easily Visualize Package Consumers with ProGet 5.3

Starting in version 5.3, ProGet offers the package consumers feature to help keep you out of Dependency Hell.

After building your application (and resolving all of those complicated dependencies), ProGet’s pgscan tool will scan the build output, search for the specific library package versions consumed by the application then publish that data to ProGet, along with your application’s name and version. pgscan is a simple, open-source command-line tool for publishing dependencies used by a package when it is built.

Instructions for using pgscan for .NET applications and for registering consumers via the deployments API are detailed in the package consumers Inedo Docs page.

Try Package Consumers

Download ProGet through MyInedo or upgrade to 5.3 from your Inedo Hub to give this feature a try. You can also request an obligation-free, 30-day free trial of ProGet Basic through MyInedo.

Crista Perlton

Crista Perlton

Navigation