NuGet Doesn't Help Me

There's been a lot of hoopla around NuGet and the whole .NET package management "thing." There's a lot of praise going around, and I think they've done a good job for what they're doing.

That said, I have what I'm sure is going to be an unpopular opinion:

NuGet doesn't help me.

It seems to me the primary benefits of NuGet are:

  • Get third-party dependencies into new projects faster.
  • Help you more easily update packages in your project.

That's all well and good, but I think I'm not the target audience for this, and I think I may not be alone.

I don't create a bunch of new projects. I work primarily in an established environment. We add new functionality to existing stuff. We refactor and fix and add features and clean up old code. We don't create a bunch of new projects. When we do, there's more ceremony than one person on the team deciding "File -> New Project." How does that new project affect our installers? How does it change our deployment model? Was there any analysis done to see if there's already a project in the system that overlaps what the intent of this new project is?

Since there aren't a lot of projects created, there's not a lot of need to hurry up and get new third-party dependencies in them.

Even if there were a ton of new projects, we have a central repository of third-party dependencies. That's necessary because we have a lot of teams working on a lot of different projects and solutions that integrate and if we don't keep ourselves unified on an agreed-upon dependency version, we have DLL Hell and Massive Assembly Redirect Configurations to maintain. Plus, there are legal issues with redistribution of libraries and licensing. Before you can update a dependency, did you check to see if the license changed? Did anyone do the cost/benefit analysis of taking that new dependency? Did someone try it in an isolated environment to see if it broke anything?

The point is, you can't just right-click and update a dependency. Maybe a more accurate statement, then, is:

NuGet solves problems I don't have.

I have other problems, sure, but NuGet isn't helping me with those.

So when I see that really great projects like AutoMapper have stopped offering a straight-up zip-file download and are making me jump through the hoops of creating a temporary location, futzing with the NuGet command line to "install a package" that I'll never use, then manually peel the assemblies out of that and delete all the package junk... I'm disappointed. I know it's free software, but that's not terribly customer-friendly.

CORRECTION: There are zip files for AutoMapper, you just have to dig for them. I have come across other projects that don't do zip downloads, though, and that's sad.

There is still something to be said for distribution in a standard downloadable zip format. I mean, whatever happened to xcopy deployment? Does it always need to be more complex than that?

It also doesn't help that the latest MVC templates all have NuGet built in. Now it's not File -> New Project and go. It's File -> New Project, delete packages.config, delete the packages folder, and go. And that's in an "empty project." Yay for additional steps!

posted on Thursday, October 27, 2011 1:59 PM | Filed Under [ .NET Visual Studio ]

Comments

Gravatar # re: NuGet Doesn't Help Me
by smnbss at 10/27/2011 2:53 PM
sure it does not help you?
you can host your company NuGet Feeds so all the projects in your company will use the version of references you have approved http://bit.ly/vnLFqL and use CI to automatically get all the projects up to date at the same time http://bit.ly/kHvvPX, or you could share your own libraries via private NuGet repository. I think you should have a second look at what NuGet can do for you
Gravatar # re: NuGet Doesn't Help Me
by Travis Illig at 10/27/2011 3:32 PM
Yes, I'm aware of the private feed ability and decided not to go off on that tangent.

We currently have a really nice solution using Subversion svn:externals references that allows simple, central management of this stuff.

As the dependencies are checked in (regardless of whether it is our current system or a proposed NuGet system), the CI solution won't work. I don't want my CI system doing any commits to my repository beyond tagging. Updating needs to be a conscious choice that's tested by a person before getting committed.

It's also not one single solution, so that means a proliferation of packages.config files and packages folders, which sucks. To the best of my knowledge, I can't say, "Use this central packages.config and packages folder, thanks."

So, yes, I know it does all that stuff, but no, it still doesn't help me.
Gravatar # re: NuGet Doesn't Help Me
by xavierdecoster at 10/27/2011 3:36 PM
One think you are missing (as do I for the moment), is a download package link on the NuGet.org gallery. I hope it's coming, but I know we already provide this option on MyGet.org.
This way, you can simply download a NuGet nupkg, extract it with your favorite archive utility, and xcopy binaries from its lib folder to wherever you want.

Start with smaller projects that start consuming packages that you know from trusted publishers and see how it goes from there.

Also try to think about what strategy you could use for your environment. Think outside of the box: there's more than just the public feed. You don't have to stick with a single feed either.
You don't "have" to create your own nuget server, start with a simple repository (network share for instance) and use UNC paths instead of the odata feed. If you need more, maybe give MyGet a try and play with different set ups. If you still find it not suitable to your needs, then who am I to say otherwise.

Moving forward, I think NuGet will become part of the default .NET developer toolbelt, although you're not forced to use it. You're not forced for instance to use Visual Studio either for that matter.

Cheers,
Xavier
Gravatar # re: NuGet Doesn't Help Me
by Travis Illig at 10/27/2011 3:40 PM
I think my larger point is more... that there are use cases Microsoft isn't considering. Or maybe there are certain audiences being ignored.

I admit I'm in the minority. I mean, there aren't a ton of folks wishing .NET had better native multitenant support in it, either.
Gravatar # re: NuGet Doesn't Help Me
by xavierdecoster at 10/27/2011 3:43 PM
Just noticed your earlier reply after posting my comment.

You could use a central Packages folder if you would like to. You can use NuGetPowerTools (and even customize the NuGetPowerTools package to your needs, with your defaults, and use yours instead). NuGetPowerTools allows you to redirect the Packages folder location.

Packages.config is project specific (as in solution project).

Upgrades should definitely be a conscious decision, I'm with you on that! Nothing prevents you from doing such things locally on a dev machine.
That's why I say never to auto-update pkgs as part of automated builds (cfr my post here: www.xavierdecoster.com/...)
Gravatar # re: NuGet Doesn't Help Me
by xavierdecoster at 10/27/2011 3:48 PM
you say: there are use cases Microsoft isn't considering

I'm sure there are, but as they are now starting to eat their own dogfood (haacked.com/.../semver-nuget-nightly-builds.aspx), I'm sure improvements are coming for minority audiences as well.

I'm sure your post provides valuable feedback in that regard ;-)
Comments have been closed on this topic.