Archive

Last week, Alex Papadimoulis joined Gael Fraiteur on the PostSharp Live Webinar to talk about NuGet, the popular open-source library package manager for .NET, and show how it helps developers escape from "dependency hell" while discovering new third-party libraries.

Attendees learned:

  • how developers are successfully using NuGet;
  • why PostSharp chose NuGet for deployment management;
  • what deployment management pitfalls to watch out for; and
  • when to consider solutions like private repositories.

Watch the recording and learn how to leverage NuGet and private repositories to improve your enterprise architecture.

Q&A

Q: How do you specify dependency on a version range?

A: NuGet documentation shows how to do that: http://docs.nuget.org/docs/Reference/Versioning

Q: When you install the NuGet plugin by default it is configured to pull from the public repository. How do you prevent users from pulling packages from this public NuGet repository? Is this a specific configuration change?

A: What you have to do from a training standpoint is instruct developers to add a package source. Go to package management settings, uninclude the official package source, and add in your own corporate library. There is no good way to prevent developers from doing it themselves, so it's important to monitor your packages.config file for changes to it to ensure a bad package isn't added.

Q: How do you deal with scenarios where two packages depend on the same third package, but they depend on different versions of that third package? Visual Studio will only include one of the versions, and you will get a runtime failure.

A:This becomes tricky. NuGet attempts to add a binding redirect to mitigate the problem, but it can cause more problems than benefits. My advice is to monitor the versions that are added and that you're redirecting appropriately.

Q: Is it possible to configure NuGet for projects independently of Visual Studio solutions? What if projects appear in multiple solutions?

A: NuGet works fine if you keep your configs simple but can complex things can get a little hairy depending on your configuration. has a packages.config file, and some of the default locations for the packages file

Q: Can standard MS packages (e.g. MVC 4 bits) required by the new project dialog be routed via a private NuGet repository to make the selection / deselection of the public NuGet repository in the developer machine?

A: Yes. Select the Package Manager option in Visual Studio, where the available Package Sources are displayed, and select the source you want to use. NuGet will use whatever package source you select rather than the public source.

Q: What's the best way to enable package restore on a bulid server?

A: Package restore adds a folder to your Visual Studio solution and does all sorts of weird things with it. We recommend users not use NuGet package restore and instead have a NuGet install as part of your build server plan. We recommend this to our customers since NuGet package restore doesn't work with PostSharp. Create a build step that includes calling NuGet install before calling MS build for every file package.config you find in your source tree. It's much more reliable.

Comments are closed