PostSharp Official Blog

PostSharp Supports Prague Flood Relief: Follow-Up

Thu, 13 Jun 2013 10:01:00 PDT

On June 3rd, we announced that we would support those affected by the floods and pledged to donate to a local flood relief fund 50% of all online purchases completed during the state of emergency.

On June 7th, as floods started to subside, we sent $2,000 to Caritas, a well-known charity association.

“It is extremely important that we all band together and support one another during such difficult time. We sincerely appreciate the generosity and community spirit of all donors. Your generous help will enable us to support families affected by the flood in Kralupy and its surroundings,” says Barbora Kovarova, director of the local Caritas of Kralupy nad Vltavou.

For the whole team at PostSharp Technologies, I would like to express our warmest thanks to all customers who contributed to the donation.

-iveta

[Recording] Unit Testing & Thin Aspects

Tue, 04 Jun 2013 04:34:00 PDT

The benefits of unit testing are numerous. When aspects are involved, Matt Groves believes keeping them "thin" is key to keeping your code easy to unit test and he explores some of the implications of unit testing when a post-compiler tool is involved.

Gael Fraiteur joins this final episode in the AOP in .NET series to give his differing opinion about the relevancy of "thin" aspects and speaks about a set of practices that can be used to create efficient tests of aspects.

Q&A

Q: What would be the best way to inject the cache provider VIA an IOC container? (e.g. Autofac/Unity)

A: Whatever container you wish to use is fine. In my example I just new them up directly but in reality you shouldn't do that. In structure map you could say:

if (!On) return;

_concern=ObjectFactory.GetInstance<ICacheConcern>();

As long as you're not tying it to a specific implementation, you're just asking for something that implements the interface. This is known as the service locator pattern.

Q: Gael, you mentioned in your presentation that one can't test an aspect in isolation of a target. Isn’t that exactly what Matthew just showed us?

A: Gael – yes, but Matt showed it in a very specific case using compiler internals to do it by instantiating the execution arguments that are being passed to the aspect. In the case of OnMethodBoundary Aspects, this is very simple to do, but if there are changes in methods or invocations it can become quite complex.

Matt showed how to isolate the aspect completely from the aspect framework with the notion of thin aspects but to me the cost of doing so is huge. There is the abstraction that is added on top of the aspect which isn’t justified because test coverage is worsened and the meta data is part of the input. Just as you wouldn’t test a method without an argument, you wouldn’t test an aspect without a target.

Matt – what I tested in isolation wasn’t an aspect but rather the advice or the actual logic of the aspect.

Gael – Matt’s approach may work in simple cases but I would be curious to see how it works in complex aspects, including aspect combinations.

Q: Why would you use a static IOC resolution instead of using the service locator with each call of "OnEntry"? (in the logging example)

A: This is a matter of optimization. Logging is very performance sensitive, because it’s invoked at a very high frequency, so I would avoid resolving dynamically but this is entirely up to you. In documentation, I show several approaches where the service locator returns a delegate that may be re-evaluated each and every time (or not, depending on your preference).

There is no general rule or best practice here, it depends on what you want to achieve in each situation and the tradeoffs between architecture and performance.

Q: Gael, you mentioned in your presentation that you can’t unit test build-time logic because PostSharp performs code weaving at compile-time. For a consumer of a class or a framework, why would I be concerned on how the deliverables are made instead of how they are used?

A: It depends on who the consumer is. In large teams, you’re delivering aspects to the rest of the team and not the end customer. With some of our largest customers 10% of the team build aspects and the other 90% consume the aspects. In those cases, if you want your team to be more productive then you need to check that the aspect has correct build-time behavior. Then the problem is: how to test validation.

If however your aspect never emits build-time errors, then run-time testing may be sufficient.

Q: Couldn't you unit test the aspects advice the way Matthew suggests, and then integration test the combination and ordering of method calls of the aspects the way Gael suggests? Do these techniques really need to be mutually exclusive?

A: Gael – it depends on what your objective is. If your objective is to decouple the framework from the aspect, then Matt’s approach may be useful. However, if the objective is to do good testing in as little time as possible then why would I add complexity and decouple the framework from the aspect? I don’t see the benefit in terms of architecture and time-savings.

Matt – Gael and the PostSharp team take a different approach than I would because they’re writing aspects for the general public to consume and not just my team.

Q: In the case of injected concerns/dependencies for aspects, would you use a fake resolver?

A: Matt – in my case the aspect was thin enough so I didn’t have to use a fake resolver. What I did instead was to pass-in mock objects directly, injecting them myself.

Gael – you should have your resolver work differently, depending on the context. In production, you would involve your real resolver and in testing you would add rules. and according to the context to which the aspect is being applied, it would return a different implementation of the service. these are all options to consider.

Q: Have any of you used something like nCrunch with PostSharp?
A: Matt – I’ve used nCrunch before, it’s a great test runner tool, and haven’t had any problems with using it and PostSharp together. However it’s been a while since I last used it.

Many thanks to Matthew Groves for the wonderful 5-part series. We wish him much success with his new book, Aspect-Oriented Programming in .NET, out this month. You can see Matt speak and catch up with him in person this summer at Louisville .NET Meetup Group and CodeStock.

Alex Papadimoulis of The Daily WTF fame will join us on June 27th for the next PostSharp Live Webinar to talk about NuGet, deployment management issues, and private repositories as a possible solution.

PostSharp Supports Prague Flood Relief

Mon, 03 Jun 2013 02:46:00 PDT

When I first moved to Prague in 2004 I heard many tales from locals about the devastation caused by the floods of 2002 which killed 17 people, forced tens of thousands from their homes and caused several billion dollars of damage across the country.

I heard tales of rescue: brave souls risking their own lives to save elderly neighbors and pets.

Tales of losing it all: families without homes and cars; historic photo albums, artwork and libraries of books now gone forever.

And tales of starting over: communities coming together in solidarity to rebuild their lives; a city slowly restoring to its former beauty, one street at a time.

I remember thinking to myself, “thank god flooding like that only happens every 100 years.”

Just yesterday, Czech Prime Minister Petr Necas declared a state of emergency for most of the nation as swollen rivers caused by days of heavy rain threatened Prague's historic center and forced evacuations from low-lying areas.

And the waters are STILL rising.

In an effort to support the beautiful city to which we call home, and all those affected by the current Prague flooding, PostSharp Technologies is donating 50% of all online purchases to a local flood relief fund from now until the state of emergency is lifted.

Please keep the city of Prague and the Czech nation in your thoughts and prayers during this difficult time, and we will keep you updated on Twitter as news comes in.

Now is our chance to be part of a new tale.

-Britt

[Recording] Under the Hood of a Post-Compiler + Q&A

Tue, 28 May 2013 00:02:00 PDT

Tools like PostSharp, that manipulate the IL, can seem like black magic at first. However, the simple act of opening a decompiler changes all that. In this episode, Matt Groves shows how to decompile a .NET assembly and view code with/without a PostSharp aspect using Reflector to see exactly what’s being manipulated.

Q&A

Q: In your previous session, you used aspect boundaries to do something that could also be accomplished by method interception. What factors help to decide which way you should implement?

A: The OnMethodBoundaryAspect offers higher performance because only a part of the calling context needs to be passed to the aspect. This is especially true with the aspect optimizer feature, included in PostSharp Pro and Ultimate, when the aspect does not consume a lot of context, for instance a transaction scope aspect. The benefit is reduced however if the aspect consumes a lot of context, for instance all argument values. The MethodInterceptionAspect is more powerful: you can invoke the intercepted method on a different thread, for instance. But it is slower because the whole calling context needs to be stored to the heap and passed to the aspect.

Q: How can I disable a PostSharp aspect temporarily?

A: There are a number of ways to disable PostSharp from a specific project:

In Visual Studio, open the project properties dialog, select the right configuration, open the PostSharp tab page, and change the value of the Disable PostSharp option.
In Visual Studio, open the project properties dialog, select the right configuration, open the Build tab page, and add the conditional compilation symbol SkipPostSharp.
Define the MSBuild property SkipPostSharp=True, for instance using the command line msbuild /p:SkipPostSharp=True.

Q: Which Aspects are serialized?

A: Every aspect is serialized at compile time. You can find out more on aspect serialization in PostSharp documentation.

Q: Is there deserialization during run-time?

A: Yes, by using a decompiler you will see that PostSharp stores serialized aspects as resources, for instance the aspect I applied to the DoSomething method in the video, and an internal class does the work of deserializing the resources into an object.

Q: Why are you using the objects (internal classes) instead of writing the code directly in the corresponding methods? Wouldn't that be more performant?

A: This approach is named “aspect inlining”. It is more performant but more complex and less powerful (aspects code would need to be more limited).

Q: System.Diagnostics.Contracts also uses the post-compiler rewrite method to check state and assertions. Do PostSharp and Contracts work well together?

A: Yes, they work well together. PostSharp runs after Code Contracts.

Q: It’s evident that PostSharp is heavily dependent on using .NET's underlying support for discovering and calling methods using Reflection. Are there any significant trade-offs or compromises in using Reflection so heavily?

A: PostSharp does not rely on reflection to discover and call methods. The analysis is done completely at build time, and PostSharp generates code to call exactly the right methods. Reflection is only used if the aspects themselves use reflection. Even then, any use of reflection is optimized and cached.

Up next: Unit Testing & Thin Aspects

The benefits of unit testing are numerous. When aspects are involved, Matt believes keeping them "thin" is key to keeping your code easy to unit test. Join us this Thursday as he explores some of the implications of unit testing when a post-compiler tool is involved.

During this final episode in the AOP in .NET series, Matt will be joined by Gael Fraiteur, the creator of PostSharp, who has a differing opinion about the relevancy of "thin" aspects and will speak about a set of practices that can be used to create efficient tests of aspects.

SPECIAL OFFER:

The generous folks at Manning Publications are offering a 40% discount on Matt’s new book to all live webinar attendees. So, if you want to learn what difference AOP and PostSharp can make in your projects, and take advantage of Manning’s discount offer, be sure to join us for the last live webinar in this series.

Seats are limited and this head-to-head episode is sure to sell out so reserve your spot today.

-Britt

[Recording] Before and After: Boundary Aspects

Mon, 27 May 2013 05:19:04 PDT

Matthew Groves delivered part 3 of his 5-part live webinar series on AOP in .NET recently. The series covers insights found in his new book and a variety of real-world coding examples using PostSharp.

In part 3, Matt looks at a real-world application of a method boundary aspect to help with caching.– followed by a Q&A session.

Q&A

Q: Is OnExit always executed and, if yes, is it before or after OnSucess or OnException?

A: Imagine an invisible Try, Catch and Finally surrounding your method, then picture OnExit as being inside the Finally block of that imaginary Try/Catch block.

I say imaginary but, in the next episode, we will look at decompile and assembly and you’ll see there is a real Try, Catch and Finally block being generated by PostSharp. So, OnExit will run after OnSuccess because the code and Finally runs after the code inside the Try block.

Q: In the cache example is the data saved in the cache again, and is OnSucess even called or is it skipped because of the FlowBehavior?

A: When we set FlowBehavior to return that means OnSuccess, OnExit and OnException won’t be called at all. It will just return immediately and those boundaries won’t be executed, and it won’t be stored in the cache again.

Q: Instead of using a Cache object instantiated inside the aspect, is it possible to inject an implementation of it?

A: In my example I tightly coupled an aspect to a specific caching framework [ASP.NET cache]. If you’re suggesting I should inject a dependency so I’m working against an interface instead of directly against the ASP.NET cache, I agree with you. We’ll talk more about that in the upcoming unit testing episode, because an important part of unit testing is not having those elements be tightly coupled.

Q: How do we refresh the cache? Say if the value we are pulling from DB (say Median income) is changing every 10-15 minutes how can I keep my data up to date?

A: The answer depends on the caching framework you’re using. With ASP.NET cache it has a default expiration of around 20 minutes. You can change that if you’d like. In my example I set the cacheKey directly by writing:

HttpContext.Current.Cache[cacheKey] = args.ReturnValue

You can also use the Add method:

HttpContext.Current.Cache.Add()

Here I can add the key, the value, CacheDependency, absoluteExpiration time, slidingExpiration time, Priority, etc. So if the median income caches often, you may want to set it to expire more frequently than every 20 minutes.

Q: Are there some useful pre-built caching aspects in PostSharp?

A: PostSharp 3 currently offers ready-made aspects to handle logging, INotifyPropertyChanged and multithreading. Ready-made caching is on the horizon. In the meantime, you may want to look at Attribute Based Caching, found on CodePlex, which uses PostSharp to handle many of the implementation practices talked about today.

Q: In your upcoming book, will the examples/code work in PostSharp 2.1 or is the latest version 3 required?

A: When I started writing the book PostSharp 3 wasn’t released yet so I mostly used version 2.1 to write the code. The coding examples however should work fine in either version.

Up next: Matt Groves goes Under the Hood of a Post-Compiler, showing how to decompile a .NET assembly and view code with and without a PostSharp aspect with Reflector.

-Britt

[Recording] Call This Instead: Intercepting Methods

Tue, 21 May 2013 06:08:21 PDT

Matthew Groves delivered part 2 of his 5-part live webinar series on AOP in .NET recently to support his upcoming book Aspect Oriented Programming in .NET, out from Manning Publications in June. The series covers insights found in his book and a variety of real-world coding examples using PostSharp.

In part 2, Matt demonstrates the method interception aspect, and looks at a real-world application of the aspect that can help with data transactions – followed by a lively Q&A session.

Q&A

Q: With the use of Aspect Interceptors, does the behavior of stepping through and debugging the code in either the Interceptor or calling code change? If so, how?

A: With PostSharp, debugging works great! When PostSharp rewrites your code with IL manipulation it also makes appropriate changes to the debugging file. Which means, if you set a breakpoint in an aspect or in a method that has an aspect on it, that breakpoint will be hit when expected and you’ll get the full stack with that as well.

Q: Can you put a PostSharp attribute on an aspect’s method?

A: No.

Q: Can we apply interceptors globally to all the methods in a class?

A: Absolutely. You can apply the attribute to the class and by default it will be applied to every method within that class. There are lots of customization available with PostSharp. You can customize how you want the attributes to be applied – even at assembly level.

Q: Is it possible to apply an aspect to DLL methods to which you don’t have the source?

A: In theory yes, but this scenario is not supported so you will be on your own in case of problem.

Q: Can we apply multiple aspects to a given method, and in what order are they executed?

A: In some situations, for instance if you have caching and authorization, the order in which the aspect is applied is very important. PostSharp gives us a few ways to deal with that. The simplest one is called AspectPriority where you specify a number to indicate the order in which aspects are run, and there are more robust features that PostSharp has as well to manage dependencies between aspects and aspect composition.

Q: What are some other examples of practical uses of aspects?

A: Logging, data transactions, caching, INotifyPropertyChanged, exception handling, authorization, validation, etc. In fact, PostSharp Ultimate comes with a whole suite of aspects that have been written for you. It’s a new feature in PostSharp 3 so you don’t have to spend time writing these aspects and can simply drop them in and start using them right away.

Q: Can you add an Attribute to a parent object and have it apply to all child objects?

A: Yes, using aspect inheritance.

Q: Will you show how to TDD aspects in this series, and do you show it in your book?

A: Not TDD specifically, but I have dedicated an entire chapter of my book to unit testing aspects and episode 5 in the series (May 30th) will focus on that.

Q: Does the aspect class name need to end with Attribute, as per .NET convention?

A: No, it’s not necessary. As long as you inherit from the Attribute base class, .NET will recognize it as an Attribute.

Q: Can you use PostSharp in Windows Phone 7 applications?

A: Yes.

Q: What are the best practices for bringing dependencies into aspects?

A: That question will be covered at length during the Unit Testing Aspects episode on May 30th.

Q: When will your book be published?

A: June 14th.

If you want to ask Matt any question you may have about AOP in .NET and/or PostSharp be sure to sign-up for the series and join us every Thursday throughout the month of May.

[Recording] You May Already Be Using AOP

Fri, 10 May 2013 03:55:00 PDT

Last Thursday our good friend Matthew Groves delivered part 1 of his 5-part live webinar series on AOP in .NET. He has a new book coming out next month called Aspect Oriented Programming in .NET from Manning Publications and the series will cover some of the practical AOP insights found in his book and a variety of real-world coding examples using PostSharp.

In part 1, Matt does an excellent job of demonstrating the basics of Aspect-Oriented Programming, including a number of live coding examples using ASP.NET and PostSharp – all in under 30 minutes.

Q&A

Q: Can you provide any hints on unit testing with aspects involved?

A: We’re going to talk about unit testing aspects – unit testing code that aspects are applied to – in part 5 of this series [May 30th]. In fact, I have dedicated an entire chapter of my book to unit testing aspects.

Q: Is PostSharp the only AOP framework covered in your book?

A: My book is focused on AOP in .NET and PostSharp is a large part of that but I cover other .NET tools like Castle DynamicProxy and the ASP.NET examples [shown in the video]. The idea is that once you learn the principles of AOP, you will be comfortable using tools other than what’s covered in the book. So anything you learn about PostSharp or Castle you can apply to other frameworks as well.

I will be adding new recordings each week but, if you want to catch them live and have the chance to ask Matt any question you may have about AOP in .NET and/or PostSharp be sure to sign-up for the series and join us every Thursday throughout the month of May.

Announcing PostSharp 3 RTM

Fri, 03 May 2013 04:50:05 PDT

We’re excited to announce that PostSharp 3 RTM is now available for download from Visual Studio Gallery and NuGet. After a successful RC cycle, PostSharp 3 now enters the stable quality band and replaces PostSharp 2.1 as our featured version.

PostSharp 3 marks a huge evolution from previous versions. Designed to deliver more value with less learning, PostSharp 3 is now much more than an awesome framework: using simple smart tags in the Visual Studio code editor, you can add to your code ready-made implementations of some of the most common design patterns. Other improvements include first-class support for Windows Store, Windows Phone and Silverlight apps.

Improved Visual Studio Integration

The single most striking feature of PostSharp 3 is its deeper integration with Visual Studio.

For instance, move the caret to the name of a class or a method. Visual Studio will display a smart tag proposing actions that make sense in the current context: apply a threading model, add logging, implement INotifyPropertyChanged, …

A wizard then guides you through the configuration of the aspect.

The wizard installs all required NuGet packages and generates the code for you – so you don’t have to study documentation to figure out how it works.

Of course, you can still add aspects to your code the old good way.

Ready-Made Pattern Implementations

While talking to customers, we figured out that the Pareto law also applies to our product: 80% of customers use the same top 20% aspects. We thought we would provide more value to our customers by providing ready-made implementations for the most common patterns. The results are our three first pattern libraries:

Model Pattern Library: INotifyPropertyChanged, Code Contracts (Not Null, Positive, …)
Diagnostics Pattern Library: Logging to log4net, nlog, Enterprise Library
Threading Pattern Library: Thread dispatching, actor threading model, reader-writer synchronized threading model, verification of thread-unsafe objects

Windows Store, Windows Phone and Silverlight

In previous versions of PostSharp, support for alien .NET platforms was quite limited. The raise of Windows Phone and Windows Store stressed the importance of supporting new trends, so we decided to invest in providing first-class support for Windows Store, Windows Store and Silverlight.

I’m very pleased that we could this through Portable Class Libraries.

The first challenge was to develop a portable alternative to the system BinaryFormatter and its [Serializable] attribute. The result is the PortableFormatter class and its [PSerializable] attribute – an interesting piece of software in itself.

Deployment through NuGet and Visual Studio Gallery

When PostSharp 1 was released seven years ago, it seemed mandatory to have a setup program. Over the years, source control and build servers have conquered the world, changing requirements on deployment of development tools.

Despites important limitations, Microsoft’s NuGet and Visual Studio Gallery are becoming the de-facto standards for deployment of development components and their user interface, so we decide to get aligned with Microsoft’s lead.

We are aware of some negative consequences and will be happy to work with customers who may be affected by this choice.

Subscription-Based Maintenance Model

PostSharp 3 marks also the move from a per-version to a per-year maintenance model, as described in a previous blog post. A maintenance subscription is now included as a mandatory part of the product fee. The maintenance subscription not only gives right to major versions, but also to bug fixes.

We believe that part of our failure to deliver support for Visual Studio 2012 in time was due to our per-version revenue model. The new revenue model will allow us to release features as soon as they are needed, irrespective of the current major version number.

For more information regarding licensing and support, please read our FAQ page or contact our sales team.

Tip: Upgrade Before Summer

PostSharp 3 is now stable and it’s a good time to upgrade. During the next 2 months, the team will be ready to answer your questions and address support issues, without any other big project in the pipeline. We may be a bit slower during the vacation period, so it’s a good idea not to delay the upgrade if you can do it now.

PostSharp 3 is a big turn for our company, and so far we are very happy with the feedback and the businesses we received.

Happy PostSharping!

-gael

[Action Required] Imminent update of PostSharp NuGet package

Tue, 30 Apr 2013 03:02:00 PDT

It’s official: PostSharp 3 RC was a success and we are scheduling to move PostSharp 3 to the “stable” quality band on May 2nd. That means that, on May 2nd, the stable release of the PostSharp package on NuGet will be version 3.0. Because of the way the NuGet client is implemented and how people usually author their NuGet packages, this day may turn into a little apocalypse for some of you.

Problem 1. NuGet client in Visual Studio

The NuGet user interface in Visual Studio is hardwired to always give you the latest stable version of a Package. There is no way to specify that you want to stay in an old branch. Even if NuGet allegedly supports semantic versioning, NuGet is going to try to upgrade you to a new major version even if it not backward compatible with the old one (semantic versioning says that backward compatibility can be broken when the major version number changes).

However, PostSharp 3 is not fully backward-compatible with PostSharp 2:

There are very minor API changes, and
You will need to acquire a new license

Action Required:

Pay attention when upgrading using the NuGet user interface.
Consider using the NuGet PowerShell console with the -Version flag to specify which version you want to install, for instance:
```
Install-Package PostSharp -Version 2.1.7.30
```
Consider using ProGet Client Tools, an alternative to NuGet Client Tools that has not been optimized for for pushing the latest fresh bits to your desk, but to protect your build your breaking changes.

Problem 2. Packages with dependencies on PostSharp

NuGet packages that have a dependency on PostSharp 2 may install incorrectly after the PostSharp 3 release because NuGet is going to install PostSharp 3 instead of PostSharp 2.

Action Required:

To prevent NuGet from installing PostSharp 3, you need to edit your .nuspec file and add an upper bound to the PostSharp version:

<dependency id="PostSharp" version="[2.1,3)" />

That’s it. Happy PostSharping!

-gael

Unit Testing of Aspects

Fri, 26 Apr 2013 08:55:23 PDT

If there’s one topic that is subject to almost religious observance, this is unit testing.

There has been much hesitation in the community about how PostSharp aspects should be tested and how aspects can consume dependencies from a dependency injection container.

Obviously, we have a lot of experience testing aspects. I finally took the time to write down a set of practices that can be used to create efficient tests of aspects. I also show techniques that allow aspects to consume services from a dependency injection container. Last but not least, I publish and document a test framework for aspect build-time logic, especially logic emitting build-time errors and warnings. The framework is derived from the one we are using internally.

Conceptual Documentation Available in Print-Ready PDF

Fri, 26 Apr 2013 05:43:00 PDT

Some of you expressed the wish of to be able to read the PostSharp documentation offline on their tablet or ebook reader, so we did it. Our conceptual documentation is now available as a print-ready PDF document, and looks awesome on screen and paper.

It’s incredible the content renders to 140 pages, and it does not even include the class reference, which is still only available online or for download as a CHM.

But there’s an issue: although it looks like a book, it has been designed as a reference document and is not the best introduction to PostSharp. Online tutorials are still the preferred way to get started, and they are not included in the PDF.

Happy PostSharping!

-gael

Live Webinar Series with Matthew Groves

Fri, 26 Apr 2013 05:30:00 PDT

Mark your calendar for Thursdays in May as we kickoff a new series of live webinars with our good friend, Matthew Groves.

Matt is a developer with over 10 years of professional experience in education, consulting, and product development. He concentrates on web applications, using C# with ASP.NET, JavaScript, and PHP.

His new book Aspect Oriented Programming in .NET from Manning Publications debuts in June and we’ve put together a 5-part webinar series that will give you a taste of the practical aspect-oriented programming insights found in his book and a variety of real-world coding examples as implemented by PostSharp.

Read on to learn more about the upcoming schedule and a special offer from Manning Publications.

Sign-up for the PostSharp live webinar series today >>

SCHEDULE:

1) You May Already Be Using AOP
Thursday, May 2nd at 9:00 AM PDT |12:00 PM EDT | 4:00 PM GMT

Learn the basics of Aspect-Oriented Programming and see live coding examples of AOP frameworks that come with ASP.NET. We will also look at how to write a simple PostSharp aspect using a pattern that is similar to the ASP.NET framework.

2) Call This Instead: Intercepting Methods
Thursday, May 9th at 9:00 AM PDT |12:00 PM EDT | 4:00 PM GMT

One of the most common types of aspect is the method interception aspect, which runs a piece of code instead of the intended method. In this episode, we will look at a real-world application of the method interception aspect that can help with data transactions.

3) Before and After: Boundary Aspects
Thursday, May 16th at 9:00 AM PDT| 12:00 PM EDT | 4:00 PM GMT

A PostSharp method boundary aspect can execute code at its borders (e.g. before a method, after a method, on exception). In this episode, we will look at a real-world application of a method boundary aspect to help with caching.

4) Under the Hood of a Post-Compiler
Thursday, May 23rd at 9:00 AM PDT| 12:00 PM EDT | 4:00 PM GMT

The details of how a post-compiler like PostSharp works can be complex, but it's important to have a basic understanding of what's happening in order to make an informed decision about where and when to use it. In this episode, we will look at how to decompile a .NET assembly and view code with/without a PostSharp aspect with ILSpy.

5) Unit Testing and Thin Aspects
Thursday, May 30th at 9:00 AM PDT| 12:00 PM EDT | 4:00 PM GMT

The benefits of unit testing are numerous. When aspects are involved, keeping those aspects "thin" is a key to keeping your code easy to unit test. In the final episode we will explore some of the implications of unit testing when a post-compiler tool is involved.

SPECIAL OFFER:

Now there's even more reason to attend Matt's webinar series. The generous folks at Manning Publications are offering a big discount on AOP in .NET to all live webinar attendees. Seats are limited and this series is sure to sell out so reserve your spot today.

If you want to learn what difference AOP and PostSharp can make in your projects, and take advantage of Manning’s special discount offer, join us every Thursday throughout the month of May.

Reserve your seat for the PostSharp live webinar series now >>

Announcing PostSharp 3 RC

Tue, 16 Apr 2013 23:56:09 PDT

We’re happy to announce that PostSharp 3 has finally reached the RC quality band. This means that it is now sufficiently documented, internal testing is completed, all known bugs (except some minor ones) have been fixed, and the rate of new bug reports has significantly decreased. We plan to move to RTW with two weeks, unless important bugs delay this objective.

It is now a good time for small teams to upgrade to the new versions. The procedure is described in our online documentation. We are planning more articles and webinars regarding upgrades and deployment of PostSharp 3 in the next weeks.

Happy PostSharping!

-gael

PostSharp 3 Documentation Online

Wed, 27 Mar 2013 06:58:01 PDT

We reached one of the last milestones before the RC: publishing the documentation! You can now browse it online from http://doc.postsharp.net/.

Yet this is not a good time for all of you to rush on PostSharp 3 because I’ll have vacation (till April 7th) before the dead march to RTM. Support will be provided as usually, but we won’t do bug fixing releases until I’m back.

I like to write the documentation myself because it forces me to do a last API review and makes sure all concepts line up. Documenting is a never-ending job, and I hope this first version of the documentation cover the most important questions. Yet, there are still important holes. Let me know if you find one that is specially important to you, so I can prioritize.

This being done, the road is now clear for RC and then RTM. Finally!

Happy PostSharping!

-gael

Upgrading from PostSharp 3.0.12 to 3.0.13

Thu, 21 Mar 2013 09:19:53 PDT

We just pushed PostSharp 3.0.13 online, and this is just to inform you of the awful update procedure from previous builds.

Why is the upgrade procedure cumbersome?

PostSharp 3.0.12 included NuGet 2.1 in its payload. Unfortunately, because of limitations of the Visual Studio Extension Installer (VsixInstaller), it was not possible to install PostSharp when NuGet 2.2 was already installed. We had other problems with the way that VsixInstaller handled dependencies (I’m quite confident to say that it is a broken feature), so we decided to handle dependencies manually, without relying on VsixInstaller.

Because of the dependency to NuGet, PostSharp needed to be installed for All Users, requiring elevation during installation. But since we don’t have the dependency to NuGet anymore, PostSharp does not need to be installed with elevated privileges anymore. This is one more situation that VsixInstaller does not handle properly.

What is the proper procedure?

Since Visual Studio Extension Installer is not able to upgrade PostSharp 3.0.12 to 3.0.13, you will have to uninstall PostSharp manually.

Start Visual Studio with elevated privileges.
Go to Tools / Extensions and Updates, click on PostSharp, then click Uninstall
Install the new PostSharp

That’s it. Perhaps that was not so awful.

Remember that this procedure updates only the Visual Studio Extension for PostSharp. You can upgrade the compiler itself using NuGet.

Happy PostSharping!

-gael

PostSharp 3 Licenses Now Available

Fri, 08 Mar 2013 03:23:36 PST

It's been a few days since we released our new website. Although PostSharp 3 is still in preview, we've become confident enough in its quality to start selling licenses – with a 30% discount until we reach RTM. I wanted to quickly tell you about changes made to the PostSharp product lineup, including maintenance, pricing, and upgrade conditions.

New focus on design patterns

In the past years, we've successfully positioned PostSharp as the leading framework for Aspect-Oriented Programming in .NET. With time and customer feedback, we've realized that AOP was only an instrument serving automation and enforcement of design patterns. Unlike AOP, design patterns are readily understood and accepted by the majority. We published our view of Design Pattern Automation in a recent article on InfoQ.

PostSharp is now composed of the following members:

Pattern Libraries are ready-made solutions to the most common design patterns. We currently offer the Diagnostics Pattern Library, Threading Pattern Library, and Model Pattern Library.
The Aspect Framework allows you to automate implementation of custom design patterns.
The Architecture Framework allows you to automate enforcement of custom design patterns that need to be implemented manually.

Note that Pattern Libraries were previously incubated as a satellite project of PostSharp 2.1, where they were named toolkits. They are now an integral and supported member of our product line.

We're very proud of our new website, reflects our new vision of PostSharp. There are plenty of tutorials for beginners and intermediate users, and more are coming.

What's New in PostSharp 3?

PostSharp 3 is not just about repackaging old ideas differently. We also added a lot of new features and support for the latest platforms:

First-class support for Silverlight, Windows Phone, and Windows Store. Not only did we add new platforms, but we also brought all features to most cousins of the .NET Framework. Best of all: these platforms are supported through a single Portable Class Library, so it's now possible to write truly portable aspects. A central component of this feature is the Portable Serializer, similar in function to the BinaryFormatter (just replace [Serializable] by [PSerializable]).
Pattern Libraries, providing ready-made implementation of some the most common patterns. Improvements over PostSharp 2.1 Toolkits include better management through logging profiles, logging to Enterprise Library, code contracts, and performance enhancements.
Smart tags in the code editor help you adding ready-made aspects to your application without coding – without even reading our Getting Started. Smart tags are completed with a comprehensive wizard interface coupled with NuGet and a code generator.
Support for Visual Studio 2012, including the dark theme.
Transparency to all obfuscators: PostSharp does not rely on any string references that may be broken during serialization.
Better differentiation of "reference assemblies" and "runtime assemblies".
New approach to licensing that will allow to install the license key to source control.
Streamlined deployment through NuGet and Visual Studio Gallery

New Maintenance Model

PostSharp 2 was ruled by a "major-version" maintenance model: all updates (minor versions and bug fixes) within a major version were available for free. We released important improvements as "bug fixes": for instance, support for .NET 4.5 was included into PostSharp 2.1 because PostSharp 3 was not ready. This maintenance model created a conflict of interest between us (we need to be paid for our work) and our customers (you can't wait for a new major version to get new necessary features). It was time to change.

PostSharp now comes with 1-year of maintenance subscription included that gives you access to free updates, bug fixes and premium support. Every license key includes the subscription end date, which is tested against the build date of PostSharp. Importantly, licenses are still perpetual: if you can use a given PostSharp build one day, you can use it forever (except with the trial license).

Please read our Licensing & Maintenance FAQ for details. Note that we have an updated License Agreement that reflects these changes. If you need to continue with the previous license agreement, please contact our sales team.

New Product Line

There are now three distinct editions available.

PostSharp Express (formerly Starter Edition) – for getting started with simple custom design pattern automation. Free as in beer.
PostSharp Professional – for automating custom design patterns (aspect framework) and logging (diagnostics pattern library). Price: 449$ or 329€ including maintenance subscription.
PostSharp Ultimate – for automating custom design patterns (aspect framework) and enforcing design rules (architecture framework), includes all ready-made design pattern libraries. Price: 799$ or 589€ including maintenance subscription.

For more information, see the feature matrix of all editions. As you can see, we dropped the Personal License. On the other side, we're now offering free licenses to all freelancers and consultants, additionally to students, educational facilities, and influencers of all sorts. We're also offering a one-time 1000$ discount to all businesses enrolled in BizSpark.

Upgrade Conditions

We're giving 6 months of maintenance subscription for free to all customers:

Customers without support subscription fully-featured PostSharp Ultimate for free and get 6-months of maintenance starting from the original date of purchase. Practically, it means that this offer only applies to customers who have purchased PostSharp later than six month ago.
Customers with a current support subscription get PostSharp Ultimate for free and will receive an additional 6 months of maintenance, at no cost.
Other customers can benefit from our upgrade price (224$/164€ for PostSharp Professional or 399$/299€ for PostSharp Ultimate).

Technically, we consider PostSharp 3 mature enough for most situations. However, if you cannot afford taking risks right now (tight deadline, large team), we recommend to wait until RTM before doing the upgrade. The principle obstacle on the path to RTM is now the lack of documentation for new features and new deployment options.

Downgrade Conditions

We understand that some teams don't want to upgrade to PostSharp 3 now, and may need to acquire new PostSharp 2.1 licenses. When you acquire a PostSharp 3 commercial license, you become eligible for a free PostSharp 2.1 license. To request your license key, please contact our sales team. The offer does not apply to PostSharp Express.

Time-Limited Discount

For a limited time, we’re offering a special discount on PostSharp 3 purchases. From now until the RTM announcement, purchase any new PostSharp Professional or PostSharp Ultimate license and save 30% off your order by entering the discount code POSTSHARP3 during checkout. This offer also includes license upgrades and maintenance subscription renewals.

PostSharp 3 is going to change the way software engineers think about design patterns. Happy PostSharping!

-gael

PostSharp 3 moves from Alpha to Beta

Thu, 14 Feb 2013 09:10:24 PST

Just a very short post to update you on the status on PostSharp 3. We spent the last 2 months stabilizing the new version, polishing new features without adding any new one, adding more tests, and running test suites on all supported platforms. The team is now quite satisfied with the quality, so we decided to move the quality label from Alpha to Beta. It means that we are code complete, that no important refactoring is planned, and that the only changes should be bug fixes and documentation. We have a few minor UI and UX bugs open, but there should be nothing serious.

The main task that separates us from the Release Candidate status is API and reference documentation. That’s what we are going to work on during the next couple of weeks. The API could still change during this process because documenting also works as an excellent review process.

If you are already using PostSharp 2.1, it is now a good time to try to upgrade to the next version and see if anything goes well. We don’t recommend you to “commit” the upgrade to your main development branch yet (and the PostSharp 3 does not come with a go-production license yet), but it would really help us to have feedback from the field. To upgrade to PostSharp 3, just use NuGet package manager at solution-level and add the pre-release PostSharp package to all projects.

We’re looking forward for your feedback.

Happy PostSharping!

-gael

Detailed logging with Enterprise Library and PostSharp 3 CTP

Mon, 14 Jan 2013 00:37:55 PST

Microsoft Logging Application Block, a part of Enterprise Library, is very popular in corporate environments. As all logging frameworks, the Logging Application Block provides an infrastructure for collecting and routing log entries, but falls short at generating them. If you want to log something, you have to write code that emits this log record. But there are situations where you just want to trace the execution of every method in some part of your application so that you can troubleshoot some issue. That typically requires a lot of boilerplate code.

This is why we designed PostSharp Diagnostics Toolkit, a tool that excels at generating the boilerplate needed to emit tracing information at a very low level of details. Today, we’re proud that the toolkit also supports Enterprise Library, besides NLog, Log4Net and System.Diagnostics.

Adding tracing to your application

Seriously, adding tracing to your application has never been so easy.

First, install PostSharp 3 CTP from Visual Studio Gallery or Visual Studio Extension Manager.

Then, in the Solution Explorer, right-click on the project and choose Add > PostSharp policy

You’ll get a list of project-level policies. Choose logging.

You’re then asked which types and methods should be logged.

Here you have a chance to specify which details need to be included. There are two default profiles: log everything, and log only on exceptions. Both default profiles will include parameter values by default. You can edit the profiles and create new ones as required.

Finally, you are asked to change the logging back-end.

After confirmation, PostSharp will download the required NuGet packages and will add a [Log] custom attribute to a new file named GlobalAspects.cs.

[assembly: Log(AttributeTargetMemberAttributes = MulticastAttributes.Public,
               AttributeTargetTypeAttributes = MulticastAttributes.Public)]

Of course, you can use the full power of aspect multicasting to fine-tune the set of methods that you want to trace.

If you build and run the application, and if you have included a trace listener, you will see that all public methods of public types have been traced!

High-Performance

The Logging Application Block is a bit different from other logging frameworks in that there is no concept of “trace source”. Instead, there is a a concept of extensible log record and a concept of filters that can match any property of log records, including custom properties. This design makes Enterprise Library more flexible than other logging frameworks, but is at first sight less suitable for massive tracing because of the expense of building a log record object. Fortunately, intelligent code generation can make Enterprise Library as fast as other frameworks by sharing some read-only data structures and assuming that filters do not change when the application is executing (i.e., that a change requires an application restart).

Hierarchical categories

Another limitation, critical for automated tracing, is the lack of support for hierarchical categories. As a workaround, PostSharp will enlist each log record in several categories, one for each part of the type name and namespace.

Generated Code

For those who want to see what’s under the hood, the following snippet shows the code generated from a simple “Hello, world” method with full tracing enabled.

public static void Main(string[] args)
{
    if (<>z__LoggingImplementationDetails._3)
    {
        object[] CS$0$0__args0 = new object[] { args };
        <>z__LoggingImplementationDetails.Write((TraceEventType) TraceEventType.Verbose,
            "Entering: ConsoleApplication39.Program.Main({{{0}}})", CS$0$0__args0, 
            <>z__LoggingImplementationDetails._2.Categories);
    }
    try
    {
        Console.WriteLine("Hello, world.");
        if (<>z__LoggingImplementationDetails._3)
        {
            object[] CS$0$1__args1 = new object[] { args };
            <>z__LoggingImplementationDetails.Write((TraceEventType) TraceEventType.Verbose, 
               "Leaving: ConsoleApplication39.Program.Main({{{0}}})", CS$0$1__args1, 
               <>z__LoggingImplementationDetails._2.Categories);
        }
    }
    catch (Exception)
    {
        if (<>z__LoggingImplementationDetails._5)
        {
            Exception CS$0$2__ex;
            object[] CS$0$3__args3 = new object[] { args, CS$0$2__ex };
            <>z__LoggingImplementationDetails.Write((TraceEventType) TraceEventType.Warning, 
                 "Exception in ConsoleApplication39.Program.Main({{{0}}}):\n{1}", 
                 CS$0$3__args3,  <>z__LoggingImplementationDetails._4.Categories);
            throw;
        }
    }
}

As you can see, there is a lot of references to the class LoggingImplementationDetails. This class is generated by PostSharp. The static constructor configures prototype log entries and evaluates the filters. The Write method acts as a re-entrance guard, preventing infinite recursions typically induced by ToString when arguments get included in the logged text.

internal static class <>z__LoggingImplementationDetails
{
    // Fields
    public static readonly object[] _1 = new object[0];
    public static readonly LogEntry _2;
    public static readonly bool _3;
    public static readonly LogEntry _4;
    public static readonly bool _5;
    [ThreadStatic]
    private static bool isLogging;

    // Methods
    static <>z__LoggingImplementationDetails()
    {
        LogEntry CS$0$0__logEntry0 = new LogEntry();
        CS$0$0__logEntry0.set_Severity((TraceEventType) TraceEventType.Verbose);
        CS$0$0__logEntry0.Categories.Add("ConsoleApplication39");
        CS$0$0__logEntry0.Categories.Add("ConsoleApplication39.Program");
        _2 = CS$0$0__logEntry0;
        _3 = Logger.ShouldLog(_2);
        LogEntry CS$0$1__logEntry1 = new LogEntry();
        CS$0$1__logEntry1.set_Severity((TraceEventType) TraceEventType.Warning);
        CS$0$1__logEntry1.Categories.Add("ConsoleApplication39");
        CS$0$1__logEntry1.Categories.Add("ConsoleApplication39.Program");
        _4 = CS$0$1__logEntry1;
        _5 = Logger.ShouldLog(_4);
    }

    public static void Write(TraceEventType severity, string messageFormat, 
               object[] messageArgs, ICollection categories)
    {
        if (!isLogging)
        {
            isLogging = true;
            try
            {
                LogEntry CS$0$0__logEntry0 = new LogEntry();
                CS$0$0__logEntry0.set_Severity(severity);
                CS$0$0__logEntry0.Message = string.Format(messageFormat, messageArgs);
                CS$0$0__logEntry0.Categories = categories;
                Logger.Write(CS$0$0__logEntry0);
            }
            finally
            {
                isLogging = false;
            }
        }
    }
}

In theory, the JIT compiler could see that the tracing block code depends on the read-only static field whose value is false, and could completely avoid to generate the logging code, resulting in zero cost in case that a given trace category is disabled.

Limitations

Perhaps the main feature that I regret is missing from the current version is support for the Tracer facility, which may be more appropriate for the low-level massive tracing we are trying to achieve. We will have to consider, in a next version, how we can make this concept fit with the current architecture of the PostSharp Diagnostics Toolkit.

Summary

Detailed tracing with Enterprise Library Logging Application Block is now easier than ever. In just a few clicks, you can add tracing to thousands of methods, with no impact or your source code and minimal impact on run-time performance.

Happy PostSharping!

Validating parameters, fields and properties with PostSharp 3

Wed, 09 Jan 2013 03:01:26 PST

A few days after Phil Haack described how to implement a null-checking aspect with PostSharp 2, it’s a good time to introduce a new feature of the refreshed PostSharp 3 CTP: validation of parameters, field, and properties.

First, you need to have PostSharp 3 CTP (3.0.5) installed.

To add a contract to to a parameter, just position the caret to the parameter name and select the relevant smart tag:

After you click on the action, PostSharp will download and install the relevant NuGet packages to your project, and add a [Required] custom attribute to the parameter. The same works for fields and properties.

It could not be easier. Of course, you can also introduce contracts without the user interface by installing the package PostSharp.Toolkit.Domain and adding the custom attribute yourself.

public void Foo( [Required] string bar )

(Make sure to allow pre-releases if you install the package manually.)

Ready-Made Contracts

The following contracts are available in the PostSharp.Toolkit.Contracts namespace, depending on the type of the field, property or parameter:

NotNull	Requires a non-null value
NotEmpty	Requires a non-null and non-empty string or collection
Required	Requires a non-null object or a non-whitespace string
CreditCard	Requires a valid credit card number
EmailAddress	Requires a valid email address
Phone	Requires a valid phone number
RegularExpression	Requires a match of a regular expression
StringLength	Requires a string of a given length
EnumDataType	Requires a valid value for an enumeration (can be applied to strings and integers)
GreaterThan	Requires a value greater than a threshold.
LessThan	Requires a value less than a threshold.
Positive	Requires a value greater or equal to 0.
StrictlyPositive	Requires a value strictly greater than 0.
Range	Requires a value within a range.

High Performance and Flexibility

Unlike previous validation aspects based on OnMethodBoundaryAspect, the new aspects result in compact and fast code, with almost no overhead compared to hand-written code.

Yet, they are based on an abstraction that you can extend to develop your own contracts: ILocationValidationAspect<T> is a new aspect primitive designed specifically for the task. It works transparently for fields, properties, and parameters.

If you want to create your own contract, you can derive a class from System.Attribute, or preferably PostSharp.Extensibility,MulticastAttribute (which supports inheritance, see below), and ILocationValidationAspect<T>, where T is the type of values to be validated, as many times as necessary. Note that the aspect does not know any standard type conversion (other than down-casting, which is not a conversion), so you will need a lot of these Ts, for instance for int, int?, long, long?, and so on if you want to target numbers.

Contract Inheritance

If you apply a contract to a parameter of an interface, abstract or virtual method, any the contract will be implemented in any derived method, for instance:

interface IFoo
{
   void Bar( [Required] string fooBar );
}

class Foo : IFoo
{
   public void Bar( string fooBar ) 
   {
      // PostSharp will inject the [Required] contract at the top of this method body.
   }
}

Note that inheritance is a feature of MulticastAttribute and not just contracts, so you can use it with just any aspect.

Limitations

I already mentioned that the aspect does not support any type conversion, which could be annoying if you need to develop contracts that work on numbers.

Also note that the aspect is not yet able to validate output argument and return values. It is purely a precondition checker.

Finally, note that all contracts are opt-in. There is no “not-null by default”. It would be fairly easy to develop such a policy using an assembly-level IAspectProvider, but currently you have to do it yourself.

Summary

PostSharp 3 introduces a new aspect primitive that is optimized to validate fields, properties, and parameters with high run-time efficiency. The PostSharp Domain Toolkit contains a set of standard contracts that you can add to your code easily – just using the smart tags in Visual Studio.

Happy PostSharping!

-gael

Announcing PostSharp 3 CTP

Mon, 26 Nov 2012 03:10:54 PST

The PostSharp team is excited to announce today the first public release of PostSharp 3, available for download on the Visual Studio Gallery and NuGet (make sure to allow prereleases).

This release marks an important turning point in the way we talk about PostSharp. During the last 8 years, we have successfully positioned PostSharp as the leading framework for aspect-oriented programming in Microsoft .NET. We provided an abstract construction kit and told customers they could build “whatever they wanted” with it. However, we became increasingly aware that the vast majority of our customers were all re-implementing the same aspects.

In addition to just providing a wonderful framework, we now offer more value to our customers by delivering ready-made implementations of the most common design patterns that hang over application development today:

Logging for System.Diagnostics, NLog, Log4Net (Enterprise Library coming soon);
Design patterns for safe multithreading;
INotifyPropertyChanged beyond the obvious;
Architectural validation;
Change tracking and undo/redo (coming soon);
Value validation: not null, regular expression, range, custom rules, … (coming soon);

Long-time PostSharpers know that we already started building on this vision nearly a year ago with our PostSharp Toolkits, published as free add-ons to PostSharp 2.1 Pro Edition. Although the toolkits have always been an important part of our vision for PostSharp 3, we wanted to nurture these projects jointly with our community and release them continuously. The incubation period is now over, and we are happy to announce that PostSharp toolkits will join our product line as first-class members.

With PostSharp 3, not only do we provide ready-made solutions to top problems, but we also make these solutions much more accessible than ever. With the new content-sensitive smart tags and wizards, you will be able to implement design patterns in a matter of minutes, without need to read extensive documentation.

So, beyond the new orientation, what’s new in PostSharp 3?

Smart tags and wizards in Visual Studio

The single most striking feature of PostSharp 3 is its deeper integration with Visual Studio.

A wizard-like user interface then collects all relevant settings and performs the required operations, such as installing a NuGet package and adding a custom attribute to your code.

Support for Visual Studio 2012

Visual Studio 2012 is now fully supported. Windows Store projects are supported too (see below). Visual Studio 2010 is still supported at an equal level of features, but support for Visual Studio 2008 has been discontinued.

First-Class Support for Windows Store Apps, Silverlight, and Windows Phone

Silverlight and Windows Phone (previously .NET Compact Framework) have been supported since PostSharp 1.5, but only a small subset of features was actually available for these platforms. This limitation was due to the inability of previous versions of PostSharp to execute, at build-time, code that was linked to exogenous platforms. Concretely, this affected features such as CompileTimeValidate, CompileTimeInitialize, IAspectProvider and MethodPointcut.

Thanks to some significant engineering effort, this limitation is now removed and all PostSharp features are now equally available on all supported platforms.

Support for Portable Class Libraries

Exogenous platforms are now supported through a single Portable Class Library that can target .NET 4.0, Silverlight 4, Windows Phone 7, and Windows Store 8. Therefore, it is now possible to create portable aspect libraries.

Note that a separate version of PostSharp.dll is still available for .NET 2.0. Unlike the portable version, this one supports serialization of aspects through the BinaryFormatter and provides backward compatibility not only with previous versions of .NET, but also with previous versions of PostSharp.

Because the BinaryFormatter is not portable, we had to develop our own portable serializer. Unlike other formatters readily available with the portable class library, and just as the BinaryFormatter, our implementation serializes the internal object structure (i.e. fields, and not public properties) and supports cyclic object graphs. To use the portable serializer, just use [PSerializable] instead of [Serialiable] and [PNonSerialized] instead of [NonSerialized]. This alone is already a pretty piece of software!

In order to provide support for portable class libraries, we had to do some breaking changes in PostSharp.dll. Specifically, the interface _Assembly is now replaced everywhere by the class Assembly. We had to use the interop interface _Assembly in previous versions of PostSharp because the class Assembly used to be sealed. Since _Assembly is not portable and Assembly is now portable and abstract, we decided to make this breaking change.

Practically, it means that PostSharp 3 won’t compile aspects linked to a previous version.

Unified Deployment Experience

As industry has evolved since PostSharp’s debuts in 2004, we decide to embrace Microsoft’s new vision of development tools deployment. PostSharp distribution is now clearly split into two parts: the compiler is now only distributed as a NuGet package and published on the NuGet Gallery, and the user interface is shipped as a VSIX package and published on the Visual Studio Gallery.

Feature Scavenging

It’s sometimes necessary to make difficult choices and discontinue support for scenarios that seem no longer central. That’s what we did with the following features:

Support for Mono as a build platform,
Support for Visual Studio 2005 and .NET 3.5 as a build platform (.NET 2.0 is still supported as a runtime platform),
Support for .NET Compact Framework (Windows Phone 7 is supported through the Portable Class Library),
Support for Silverlight 3 (Silverlight 4 is supported through the Portable Class Library),
Diagnostic build,
Diagnostic console,
Windows Installer distribution,
Zip package distribution.

Customers who rely on these features have the possibility to keep using PostSharp 2.1, which is still maintained. Also, note that the user interface of PostSharp 3 is compatible with the compiler of PostSharp 2.1, so side-by-side usage is possible.

Commercial customers who are severely affected by these deprecations are invited to contact us directly.

Continuous Delivery and Subscription-Based Maintenance

As of PostSharp 2.1 we officially switched to a continuous delivery process. We abandoned the distinction between “milestone releases” and “hotfixes” to assure that our customers will always have the latest build from the download page on our website, as well as on NuGet.

All paid PostSharp 3 licenses will come with subscription-based maintenance including 1 year of free updates, web-based technical support, phone support, remote assistance and issue escalation. Maintenance subscriptions are renewed annually with multi-year subscriptions available. Pricing for all PostSharp 3 editions will be announced shortly.

Conditions for Free Upgrade

Those who recently purchased PostSharp 2.1 without support subscription will be eligible for a free upgrade to PostSharp 3, with 6 months of free maintenance from the original date of purchase. This offer is valid only for customers who purchase PostSharp 2.1 within 6 months of the official PostSharp 3 release, scheduled for Q1 2013.

Current PostSharp 2.1 customers with support subscription can upgrade to PostSharp 3 and will receive an additional 6 months of maintenance to their subscription – at no cost.

Limitations

Note that PostSharp is currently in pre-release quality. It comes with several minor issues and the following limitations:

All new APIs are still subject to change.
Support for obfuscation is not yet available for portable class library.

Summary

Starting today, you will hear much less about aspect-oriented programming from us and much more about patterns. Engineers need patterns because they have been proven to reduce complexity and PostSharp provides ready-made implementations of some of the most common patterns found in .NET applications. Furthermore, PostSharp helps you to build custom design patterns of your own, implement them automatically, and validate that they have been implemented properly. AOP remains at the heart of PostSharp as one of the enabling technologies, but now PostSharp adds even more value to software engineering.

Happy PostSharping!

-gael