Archive

We’re excited to announce the first public preview of PostSharp 5.0, available for download from our website and from NuGet Gallery (make sure to enable pre-releases). Starting from today, we’re going to update the preview every third week.

In this blog post, I would like to focus on the most demanded feature that is already present in the current preview: Support for .NET Core 1.0 (CLI).

After so many unsuccessful platforms pushed by Microsoft during the last years (I’m thinking of you, Windows Phone), it’s good to see real customer demand for .NET Core. Some corporate customers already see .NET Core as a successor to Java, captured in the hands of the evil Oracle. We’re excited to see some real enthusiasm (not just marketing-driven hype) for the initiative.

TL;DR

PostSharp 5.0 has partial and unfinished support for .NET Core 1.0.

To add PostSharp to your .NET Core projects, follow the procedure described in this KB article.

Limitations

However it’s a real challenge for us to support this platform, so we have split the effort into several phases. Our objective with PostSharp 5.0 is to build on Windows, run everywhere. Today, we’re releasing the first bits. However, the work is still in progress, and you will see more features appear in the next previews.

The following NuGet packages have already been ported to .NET Core 1.0:

  • PostSharp
  • PostSharp.Patterns.Common
  • PostSharp.Patterns.Diagnostics
  • PostSharp.Patterns.Diagnostics.Console
  • PostSharp.Patterns.Diagnostics.AspNetCoreLogging

A few notes and disclaimers: it is not clear yet whether PostSharp 5.0 RTM will support .NET Core 1.0 or .NET Core 1.1 with its new build system based on MSBuild and CSProj. We will take the decision once the roadmap of .NET Core 1.1 will be clearer. Keep in mind that we may drop support for .NET Core 1.0 before PostSharp 5.0 reaches RTM.

Note that we’re prioritizing our work according to the needs of our commercial customers. If you’re a commercial customer and interested in .NET Core, please reach out to our technical support and express your priorities.

Splitting of Tools and Redistributable Packages

More and more customers are using NuGet as an internal vehicle to distribute binaries across different development teams. They use an internal repository, to which the continuous integration system automatically uploads successful builds. Many of these customers have requested a way to express a run-time dependency on PostSharp without necessarily including PostSharp in the build process. You may have of course the same requirements if you want to upload to the public NuGet Gallery a package built with PostSharp, but which can be referenced without requiring the referencing project to be enhanced by PostSharp.

For this scenarios, it became necessary to split all packages into a run-time part and a build-time part. Furthermore, .NET Core requires build-time tools and run-time dependencies to be packaged separately.

Therefore, we decided to split all packages into two parts: one package with the run-time assets, and another package with the build-time assets.

Although the most popular convention seems to be for the build-time package to have the BuildTools suffix, we decided otherwise in order to maintain backward compatibility. We will be following another popular convention, where the build-time package will be unsuffixed, and the run-time package will have the Redist suffix. (Note that the current preview has the Redistributable suffix. This will be changed in the next preview.)

We’ve already split the PostSharp package in two parts. In the next previews, we will continue and split all relevant packages.

Summary

We’ve done good progress in supporting .NET Core 1.0 and will do more during the next weeks. Feedback? Questions? Don’t hesitate to share them as comments to this blog post.

Happy PostSharping!

-gael

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.

Command-line tool

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)]

Summary

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.

Happy PostSharping!

-gael

 

White Paper

Developers spend up to 20% of their time writing repetitive code that machines could generate more reliably. Download our new white paper 10 Reasons You MUST Consider Pattern-Aware Programming that explores the problem of duplicated source code that stems from manual implementation of patterns and reveals how to automate the boring side of programming and get a 19x ROI.

The document provides insight into:

  • why repetitive code is a major source of pain
  • what technologies for pattern automation exist today
  • why you should consider a pattern-aware compiler extension
  • what investment gains you should expect

 

The white paper was written for CTOs, software architects and senior developers in software-driven organizations—specifically in financial, insurance, healthcare, energy and IT industries that typically write a lot of repetitive code.

 

Webinar

Additionally, we hosted a webinar that covers the white paper topics. Watch the recording and learn about the consequences of boilerplate code and how to eradicate it with pattern-aware programming. You can also download the slides.

 

About the speaker, Gael Fraiteur

Gael started programming as a kid and never stopped - building and selling his first commercial software at age 12. He is the Founder and CEO at PostSharp Technologies, a widely recognized expert in aspect-oriented programming and pattern-aware programming, and speaks at developer events in Europe and the United States.