Today we’re excited to announce the release of PostSharp 4.3 RTM, available for download on Visual Studio Gallery and NuGet. PostSharp 4.3 addresses the most important concerns of current customers. It focuses on improving the current experience without adding brand new features.
In a nutshell, PostSharp 4.3 brings you:
- Improved build-time performance: up to 3x faster
- Improved debugging experience
- Alternative to NuGet-based deployment
- Command-line tool
- Improvements in the NotifyPropertyChanged aspect
- Some licensing goodness for everybody.
You can watch the recording of the webinar What's New in PostSharp 4.3 that shows the updates of the new version.
Let’s look at these improvements one by one:
Improved build-time performance
PostSharp 4.3 is up to 3 times faster than PostSharp 4.2. The real figures will depend on the number and size of your projects, how many aspects are being used, and whether you enabled the solution-wide build optimizations. This option can be found under the PostSharp tab of the Solution properties in Visual Studio.
What is does is to try to build the whole solution in a single AppDomain (or as few as possible) so the overhead per project is much smaller.
Improved debugging experience
Debugging an application enhanced with aspects is now even easier thanks to the following improvements:
Full support for Just My Code.
During Step Into, aspect code is now stepped over by default.
The call stack no longer contains PostSharp implementation details by default.
To learn more about these features, see the blog post New in PostSharp 4.3 Preview: Improved Debugging Experience.
Alternative to NuGet-based deployment
Between versions 3.0 and 4.2, the PostSharp compiler and libraries were only distributed as NuGet packages. Let’s face it: some companies did not like this at all that we forced them to use NuGet. Starting from version 4.3, we are re-introducing the old good zip file, and integrate it better with PostSharp Tools for Visual Studio.
For more information, see the blog post New in PostSharp 4.3 Preview – An alternative to NuGet.
Using PostSharp as a command-line tool is now a supported and documented scenario. It means you can now even instrument assemblies that you are not building yourself – whether or not you have its source code.
You can see how it works in the blog post New in PostSharp 4.3 Preview: Command-Line Interface.
Some licensing goodness for everybody
We hate licensing just as you do but we’ve working on it in PostSharp 4.3 and we’re glad to come with two major improvements:
- You no longer need a license to build source code that you just checked out from Git or TFS but did not create/edit yourself.
- The limitations of PostSharp Express for new users are now much simpler: you get everything of PostSharp Ultimate, but only if you add aspects to 10 classes per project.
Improvements in the NotifyPropertyChanged aspect
Due to popular demand, we’ve added support for Caliburn.Micro and MVVM Light.
We’ve also added an option to suppress false positives. To enable the option (which has some runtime overhead and is disabled by default), set the PreventFalsePositives option when constructing the NotifyPropertyChanged aspect:
[NotifyPropertyChanged(PreventFalsePositives = true)]
With PostSharp 4.3, we’ve been addressing the top concerns of existing customers. PostSharp users will spend less time waiting for the build and will be much more productive while debugging. Plus, there’s a ton of improvements to make the deployment and the licensing of PostSharp easier.
PostSharp 4.3 is fully backward compatible with PostSharp 4.2, so it’s safe to update today.
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.
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.
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.