What’s still wrong with NuGet?
Clearly, the first version of NuGet was designed to make it easier to get started with new projects on the .NET platform. Get people create a prototype with the less possible friction, so they get addicted to the platform, and are then more likely to accept its limitations. There used to be a lot of criticism in the first years regarding the use of NuGet in the long term. Many limitations have been addressed in NuGet 3. But there are still a lot of good reasons why large teams are right to reject NuGet.
1. NuGet Versioning Hell
One of the main problems of NuGet is that packages are versioned at project-level. If you have several projects, each one can reference a different version of the same package, and it can be difficult to reconcile the conflicts. The problem was exacerbated by the fact that NuGet would select the latest version of a package by default when installed into a project, regardless of the version installed in other projects in the same solution.
Fortunately, the problem was partially solved with NuGet 3. You can now select versioning policies, and it became easier to consolidate versions in the same solution. That seems very reasonable, but this is still insufficient.
A large customer of us has more than 200 developers on the team, more than 100 projects spread over a dozen of solutions. How can you maintain versioning in this setup? Can you imagine the pain of the build manager? For sure, he does not like NuGet. And he probably didn’t like us neither, because we forced him to use NuGet. No longer.
2. Lack of Trust in NuGet Gallery
Another frequent criticism of NuGet in large teams is that it makes it too easy for anyone to pull a dependency. Taking a dependency on a third-party component is a serious decision. Somehow, NuGet makes it too easy to do the wrong thing.
It’s not really NuGet’s fault, it’s rather because of the public NuGet Gallery, which contains unverified packages. Some companies may want to block access to nuget.org for good reasons. For these customers, we propose the curated package source https://www.postsharp.net/nuget/packages.
Using PostSharp without NuGet
As an alternative to NuGet, we’re re-introducing the folder-based distribution starting from PostSharp 4.3. The feature is hidden by default because we believe this is a minority use case.
To install PostSharp in a solution without using NuGet:
- In Visual Studio, go to PostSharp / Options / General / NuGet and check the option Always ask before using
NuGet Package Manager.
- In the Solution Explorer, right-click on the project and then on Add PostSharp to project.
- In the wizard, select Install PostSharp into a new folder then select the installation folder of
PostSharp.
As a result:
- PostSharp compiler tools and libraries will be copied to the folder you specified.
- A MySolution.pssln file will be created to store the location of the PostSharp folder, so that we don’t need to ask the next time you add PostSharp to a project of the same solution.
- The project file (csproj) is modified to reference the copy of PostSharp installed in the specified folder.
Updating PostSharp without NuGet
Once you are using PostSharp in a solution (or set of solutions) without NuGet, it is very easy to update it. You just have to download the zip distribution from our web site (a file named PostSharp-4.3.x.zip) and extract it to the installation folder. That’s all. Because the folder name does not include the version number, there is no need to go through all projects and change references. What a relief!
Summary
One size does not fit all. NuGet does not work for everybody. Now you can hate NuGet and still love PostSharp. There is no conflict. Starting from PostSharp 4.3, we give you an option to simply extract the product to a folder and reference it. No more versioning hell, no more update headache.
Happy PostSharping!
-gael
P.S. This post is the second in a series dedicated to the new features of PostSharp 4.3:
- Command-Line Interface;
- Improved Debugging Experience;
- Alternative to NuGet deployment.