Archive

We’re excited to announce that PostSharp 5.0 RTM is out and ready for download on Visual Studio Gallery and NuGet. The long awaited new version adds support for .NET Core 1.1, Visual Studio 2017 and C# 7.0. It also introduces brand new features like the OnInvokeAsync advise, the [Cache] aspect, or the [Command] and [DependencyProperty] aspects for XAML applications. And the Logging feature has been completely revamped, now fully customizable and faster than ever.

As in any major version, PostSharp 5.0 is the opportunity for us to do some clean up at the cost of a few breaking changes. We’re also updating our product line, renaming products and regrouping features differently. The most disruptive change will affect PostSharp Express users.

New Platforms

Visual Studio 2017 – We support the new MSBuild project format, side-by-side installations of VS, lightweight solution loads, and achieved significant performance improvements.

C# 7.0 – We tested and fixed all aspects with the new features of C# 7.0, including value-typed tasks and multiple return values.

.NET Core 1.1 – You can now build applications that run on .NET Core 1.1, but you can still only build and debug them on a Windows machine running Visual Studio. Support for .NET Core is a long-term project and you will see gradual improvements in future versions.

.NET Standard 1.3 – Support for .NET Core is achieved through .NET Standard, so you can use PostSharp in your own .NET Standard class libraries.

New Features

Async support in aspects – We’ve closed the gaps in the support for async methods in aspects OnMethodBoundary, so ReturnValue and FlowBehavior are now properly supported. In MethodInterceptionAspect, we’ve added an advice method OnInvokeAsync to handle async methods.

Caching – We've added a brand new ready-made caching framework, which includes not only a caching aspect, but also a cache invalidation aspect. PostSharp Caching 5.0 comes with support for MemoryCache and Redis. See Caching reference documentation for details.

Logging – That's a complete rewrite! The new PostSharp Logging is fully customizable and faster than ever. See Logging reference documentation for details.

XAML – If you're writing XAML applications, you probably wrote a lot of boilerplate code for commands and dependency properties. We've created new aspects to automate that. See XAML reference documentation for details.

Code Contracts – It is now possible to add code contracts to return values and out or ref parameters. The values are validated when the method succeeds.

Architecture Framework – We’re adding NamingConventionAttribute, ParameterValueConstraint  and  ReferenceConstraint.

Deprecated Platforms

Windows Phone, WinRT, Silverlight – These platforms have never got any traction among PostSharp users and we will no longer support them.

Portable Class Libraries – An evil that’s no longer necessary. We’re glad to deprecate them too.

Xamarin – We still believe in Xamarin but had to make choices to reach the 5.0 finish line. We chose to suspend support for Xamarin. Our intention is to get back to work on this platform, but to support it through .NET Standard.

Changes in the Product Line and Licensing

In PostSharp 5.0, we’re reshaping our product line:

  • PostSharp Professional becomes PostSharp Framework and now includes everything you need to automate the implementation or validation of your own patterns, including the Architecture Framework which used to be a part of PostSharp Ultimate. However, PostSharp Diagnostics is removed. PostSharp Professional customers will be offered a free subscription to PostSharp Diagnostics for the whole duration of their PostSharp Professional subscription that has already been paid for. Please contact our sales team if you’re interested. Support for the license server is also removed. Please contact us if you’re impacted.
  • PostSharp Ultimate now has a big brother named PostSharp Enterprise. PostSharp Ultimate will still be an “all you can eat” version: the difference is that PostSharp Enterprise will address the typical non-technical requirements of large companies, namely custom license agreement, on-premises license server, and blueprint source code license. Please contact us if you have a PostSharp Ultimate license and are using the license server.
  • PostSharp Model becomes PostSharp XAML, the must-have companion to your XAML development. Besides NotifyPropertyChanged, undo/redo and code contracts, we’re adding command and dependency property aspects.
  • PostSharp Diagnostics now has a free edition named PostSharp Diagnostics Developer Edition and no longer has any project size limitation. It means you can now add logging to your whole solution for free. There is however a time limitation: your applications will stop logging one day after they have been built. If you need logging, you have to rebuild them. That’s why we call it the Developer Edition.
  • PostSharp Express is renamed PostSharp Essentials. PostSharp Essentials is a free but limited edition of PostSharp. You can use all the features of PostSharp Ultimate, but the number of enhanced classes is limited to 10 per project or 50 per solution as in PostSharp 4.3. Additionally, it includes the time-limited PostSharp Diagnostics Developer Edition. We have removed the licensing mode that enabled for backward compatibility with PostSharp 2.0-4.2.

The next table summarizes the licensing changes:

New Product

Previous Product

Changes

PostSharp Enterprise

PostSharp Ultimate

Tiered licensing, min. 50 licenses.

More enterprise licensing options.

Source code blueprint license added.

PostSharp Ultimate

PostSharp Ultimate

Support for the license server removed.

PostSharp Framework

PostSharp Professional

PostSharp Diagnostics removed.

PostSharp Achitecture Framework added.

PostSharp Essentials

PostSharp Express

Backward-compatibility mode with PostSharp 4.2 licensing removed.

PostSharp Diagnostics Developer Edition added.

PostSharp Diagnostics

PostSharp Diagnostics

Tiered licensing.

Totally revamped product.

Code contracts added.

PostSharp XAML

PostSharp Model

Command and dependency properties added.

PostSharp Threading

PostSharp Threading

Code contracts added.

 

So you’re now asking money for a feature that used to be free?

We hate Orwellian language just as you do. Yes. We’re removing free features from PostSharp Express. We have decided to move from a licensing concept based on feature limitations to a concept based on scale limitations. We have made a first step in August 2016 with PostSharp 4.3, but since it was a minor release, we did not want to break backward compatibility. Therefore, we still included (but did not document) a backward-compatible licensing mode in PostSharp 4.3. We’re now removing this mode. PostSharp 5.0 works exactly as PostSharp 4.3 was advertised to work, minus the backward compatibility with PostSharp 2.0-4.2.

What if you’ve been using PostSharp Express for a long time and you don’t fit within the limitations of PostSharp Essentials? I understand you wish to continue the same features for free in PostSharp 5.0 and may feel pushed into the corner by the new licensing model. You have several options:

  1. Do not upgrade to PostSharp 5.0. Remember that all PostSharp licenses, except evaluation licenses, are perpetual. We are not withdrawing your right to use any prior version of PostSharp. Staying with PostSharp 4.3 may be a perfectly viable option, but remember we will not implement support for new versions of frameworks, languages, or Visual Studio.
  2. Remove PostSharp from your project: use a competitor product or rewrite the boilerplate manually.
  3. Purchase a commercial edition of PostSharp 5.0.

I’m sure there is going to be some emotions out there, and we’re likely to see some angry reactions on social media. But I’m also convinced the best service we can render to the community of PostSharp users is to build a healthy, forward-looking, prosperous company, which implies to discontinue business models that have proved unsuccessful. Our decision will perhaps be unpopular, but this is a healthy, data-based one.

Summary

PostSharp 5.0 is a major release, adding support for .NET Core, Visual Studio 2017, C# 7.0, and introducing exciting new features such as a fully new logging framework, much improved support for async methods, a caching aspect, command and dependency property aspects, and much more.

We couldn’t have implemented all these new functionalities without doing a few breaking changes, which I suggest you double check before you upgrade.

PostSharp 5.0 is also the opportunity for us to reshape our product line. We’ve renamed our products, sharpened their positioning, and moved the boundaries between them. Most commercial customers will not be affected, but if you think you are losing functionalities because of these changes, please contact us to find a solution.

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

When we announced PostSharp 3.2 Preview, many of you shared your experience about the new features – especially threading models and undo/redo. We found it was such a significant release it would deserve a major version increase. So today, we’re proud to announce the availability of PostSharp 4.0 RC. There will be no PostSharp 3.2 release. PostSharp 3.2 has just been renumbered 4.0.

You can download PostSharp 4.0 RC from our web site. After you install the Visual Studio Extension, you can update your existing projects using NuGet Package Manager, by enabling the “pre-release” option.

What’s New in PostSharp 4.0?

Write thread-safe code in C# and VB using threading design patterns

Multithreading is difficult because we are reasoning about it at an absurdly low level of abstraction. Functional programming languages attempt to solve this problem by forcing you into a specific threading design pattern: Immutable Object. However, object-oriented programming is the right paradigm for most business applications.

PostSharp 4.0 brings the benefits of threading patterns to C# and VB. Instead of migrating your whole project to a different language, mark individual classes with one of the following custom attributes: [Actor], [Immutable], [Freezable], [Synchronized], [ReaderWriterSynchronized], [ThreadAffine] or (the anti-model) [ThreadUnsafe]. PostSharp will then ensure that your code is correct against the model, and will block you deterministically if this is not the case.

For more information, read Working with Threading Models in our documentation.

Implement Undo/Redo at model level

Undo/redo is one of the most-wanted features, but it is often absent from custom applications because it is so expensive to implement. There is no longer an excuse. The new [Recordable] aspect causes any change to your classes to be recorded, so they can be undone at any time. We provide ready-made buttons for WPF, but you can also build your own easily for Windows Phone or Windows 8.

For more information, read Implementing Undo/Redo in our documentation.

Aggregatable and Disposable Patterns

Aggregation – the parent/child relationship – is a fundamental concept of object-oriented design and a part of the original UML specification. Several design patterns rely on object aggregation. Despite its importance, the idea has not been implemented into programming languages, and is therefore the cause of much boilerplate code in most business applications.

For more information, read Implementing Parent/Child Relationships in our documentation.

Other enhancements in PostSharp Pattern Libraries

NofityPropertyChanged performance

We optimized performance of our famous NotifyPropertyChanged aspect. It is now 4 times faster at runtime.

Improved deadlock detection

The policy now also detects deadlocks involving synchronous calls to the WPF dispatcher.

Enhancements in PostSharp Aspect Framework

Dynamic Advices

In PostSharp 3.1, some advices were purely “static”. Either they were in the aspect, either they were not. In PostSharp 4.0, an aspect can take decisions dynamically about which advices must be added to the target class and members by implementing the IAdviceProvider interface. The interface allows to provide instances of one of the following advices: IntroduceInterface, ImportLocation, ImportMethod, IntroduceMethod.

Aspect Repository

It is now possible for an aspect to know which other aspects have been added to any declaration thanks to the IAspectRepositoryService. Plus, the AspectDiscoveryComplete event allows to run execute logic (typically for validation) after all aspects have been discovered.

Initialization Advices

OnInstanceConstructedAdvice lets you execute code after all constructors of a method have completed. We also added InitializeAspectInstanceAdvice, which extends RuntimeInitializeInstance with a parameter telling for which reason the aspect instance is being initialized.

Faster advice state lookup

Thanks to the DeclarationIdentifier property, it is easier to uniquely identify a member within a type. State can now be stored in an array instead of a dictionary, which makes lookups much faster. We use this feature to persist analysis results at build time and consume them at runtime.

Enhancements in PostSharp Core

Support for C++ assembly references

We solved issues where it was not generally possible to add aspects to a C#/VB assembly that referenced a C++ .NET assembly. The previous workaround (which was to use the managed host) is no longer necessary.

Support for WinRT and Windows Phone 8.1

We completely redesigned our support for .NETCore (the intimate name for .NET on Windows 8 and Windows Phone 8.1), and this is now much more reliable than before.

What did we drop in PostSharp 4.0?

Since we’re following the rules of semantic versioning, a new major release is an opportunity to abandon support for features that caused tension in our design and engineering processes. Therefore, we discontinued the following features:

  • Silverlight,  Windows Phone 7 and Windows Phone 7.5 are no longer supported by the PostSharp Model Pattern Library. The platforms are still supported by the core product itself (PostSharp.dll).
  • The IReaderWriterSynchronized interface has been fully deprecated.

PostSharp 3.1 will remain supported for a while and minor bugs will still be fixed. Issues that require important redesign will no longer be addressed in PostSharp 3.1.

Status of PostSharp 4.0 RC

We take the word release candidate seriously at PostSharp. The RC milestone means that the following criteria were fulfilled:

  • All planned features are implemented.
  • All new APIs have been reviewed and we predict no breaking change will be necessary, even with regard to other envisioned features.
  • All features have been tested internally.
  • A zero-defect point was reached at the time of release.
  • API documentation and tutorials are complete; testers did not report discrepancies or ambiguities in the documentation.

The ball is now in your camp; we need you to try to update your solutions (in a prototype branch) to the new version, run your test suite and report any issue. We will gather feedback during several weeks and promote the release to stable after community testing.

Summary

PostSharp 4.0 proposes a realistic approach to thread-safe object-oriented applications. We believe the significance of this innovation exceeds the scope of PostSharp and perhaps even .NET, since the concepts, if proven successful, could be implemented in other programming languages by a new generation of compilers. We’re obviously very proud of this achievement, and can’t wait to get feedback from the field.

Additionally, Windows and Windows Phone developers can now add undo/redo to their application with minimal effort thanks to our new Recordable pattern – a powerful alternative to the Memento pattern.

To realize these two new major features, we had to build new abilities in our aspect framework. You can now rely on these new types of advices to build automation for your own patterns.

We need your feedback to move this release to the stable milestone. Please download it from our web site and let us know what you think.

Happy PostSharping!

-gael