We at PostSharp have always been in tension between being innovative and serving big development teams with a more conservative mindset. When we decided to fully embrace NuGet in May 2013 and deprecate our other deployment methods, we truly belonged to the believers. You know, this optimism whispering to you ear that the clouds will move away just before the party starts. Today, we acknowledge that we didn’t serve our enterprise customers well by trying to force them into NuGet, and want to provide an alternative. We’re bringing back our folder-based (zip) distribution, and are integrating it better with our Visual Studio tooling.
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!
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.
Where do development patterns fit into your world? Carl Franklin and Richard Campbell talk to Gael Fraiteur about the evolution of PostSharp into a library for implementing patterns. The combination of aspect-oriented programming and patterns is powerful - providing a means to implement a pattern while keeping it separate from your business code. Gael explores one particular family of patterns: multi-threading. PostSharp implements half a dozen different multi-threading strategies, so that you can apply the pattern as an aspect to your objects and make multi-threaded coding simpler and safer.
Listen to .NET Rocks Show 1269 and if you haven’t done it already, subscribe to the podcast and register to the fan club.
When developers first discover PostSharp and decide to give it a try, one of the most frequent feedback we hear is the lack of samples that they could just download, compile and study. After years of ignoring the problem and focusing on building (look, we don’t have a single full-time marketing person in the company!), we’ve finally decided to give it the priority it deserves.
GitHub seemed to be the right way to share the source code, but let’s face it: GitHub’s source code browser could be better. The formatting is nice and colorful but GitHub does not link references to declarations and documentation.
So we looked at another solution to complete the gaps in GitHub code browser, and this thing immediately came to our mind: the Roslyn-powered .NET Reference Source Browser which has been open-sourced. That seemed the perfect solution, but some features would potentially drag the reader’s attention away from PostSharp to implementation details of the .NET Framework, which was not our objective here. So we commented out a few lines of code in the sample browser and linked the samples source code to our documentation instead of to the .NET Framework source code. We also added support for Markdown.
Today, we’re proud to release the best sample code browser in industry! Try it by yourself on http://samples.postsharp.net/. Of course, we’re still hosting the source code on GitHub and you can download or clone all samples from https://github.com/postsharp/PostSharp.Samples.
What do you think? Do you agree we have the best sample code browser in industry? If not, which sample browser do you prefer and why?