NuGet your Enterprise?

simple talk - Taking NuGet to the Enterprise

The NuGet package manager  is a great way for developers to install and update third-party tools. It solves a lot of the problems of dependency management and integration. Is it ready for the exacting requirements of  development in the enterprise?

...

• NuGet as That Tool
• A World Without NuGet
• NuGet… to the rescue?
• Dependency Management Overview
• Brief History of NuGet
• The Enterprise Development Challenge
• Enterprise Annoyances with NuGet
• Getting around Nuget annoyances
• Private NuGet Repository
• Preparing Packages for the Enterprise
• Alternative Client Tools
• Taking NuGet to the Enterprise

Beyond Dependency Management

Several tools – both open source and commercial – have repurposed NuGet components for uses other than dependency management. While these components will obviously share NuGet’s annoyances, the same techniques can be applied to mitigate these annoyances in the enterprise.

One such tool is Chocolatey. It’s described as “somewhat like apt-get, but built with Windows in mind,” and allows users to install programs like Notepad++, Git, and 7Zip with a single command at the Command Prompt. The Chocolatey client accomplishes this by downloading the corresponding .nupkg file from chocolatey.org and executing the install.ps1 contained within.

Obviously, most of NuGet’s dependency management annoyances aren’t applicable with Chocolatey, but Package Verification, Arbitrary PowerShell Script Execution, and Unexpected Licensing are equally – if not more – problematic. But they can all be mitigated with a private NuGet repository and careful package preparation.

Another tool that uses NuGet components is Red Gate’s Deployment Manager. Essentially, it retrieves application components (which have been packaged as NuGet packages) from a private NuGet repository and deploys those components to various servers. But in this case, since the packages come from known sources (i.e. built by the organization), used outside of the context of development, and are already housed in a private repository, none of NuGet’s annoyances have transferred.

All new tools brought in the enterprise need to be carefully adopted, but as these examples show, just because a tool uses NuGet components doesn’t mean that it inherits NuGet’s annoyances. And even if it does (as is the case with Chocolatey), it’s just as easy to mitigate.

At work we had a discussion about just this yesterday, about leveraging NuGet with a private repository, primarily for sharing in-house bin's. But also to re-purpose NuGet too as a "service" repository. I hadn't thought to use a private repository for storing of third-party stuff we've licensed. In hindsight that seems to make a good deal of sense... Interesting...