Archive

TL;DR If you use .NET Standard or .NET Core, you must now upgrade to PostSharp 5.1 even if it is not RTM.

We’re happy to announce that the first preview of PostSharp 5.1 is now ready for download on NuGet Gallery (make sure to enable the “include pre-release” option) and on our website.

PostSharp 5.1 will focus on providing support for .NET Standard 2.0 and .NET Core 2.0. Our objective is to port the PostSharp compiler itself to .NET Standard 2.0 so that we can compile .NET Standard and .NET Core applications natively, without cross-compilation. PostSharp 5.1 will still only support Windows as the only build platform.

PostSharp 5.1 comes after months of increasing instability of PostSharp 5.0. Initially, we tried to implement support for .NET Standard 2.0 and .NET Core 2.0 as bug fixes on the top of PostSharp 5.0, but it proved impossible to do without a significant refactoring of our type binding logic. We decided that, in respect to our .NET Framework users, we could not afford to destabilize PostSharp 5.0 any more, and therefore that any effort to support .NET Standard and .NET Core would go into a new version.

For the same reason, we will no longer solve bugs in .NET Standard 1.* and .NET Core 1.* in our PostSharp 5.0, but only in PostSharp 5.1.

PostSharp 5.0 was significantly destabilized by the release of .NET 4.7.1 and VS 15.5. We did not anticipate the breaking changes, as Microsoft seemed to be more careful with that in the past. At this moment, we realized we passed the breaking point of our type binding component and needed a complete refactoring to isolate us from what Microsoft may deem as implementation details.

We understand that several customers are not allowed to use pre-RTM releases of a product and our decision may push them in a difficult situation. We sincerely apologize. We’re going to push hard to move PostSharp 5.1 to RTM quality as soon as possible. Currently, we consider PostSharp 5.1 to be more stable than PostSharp 5.0, but it lacks testing in the field and customer feedback.

Happy PostSharping!

-gael

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