Archive

I took the last opportunity to change the public interface of PostSharp Laos. Hopefully, for most of you, the changes will be trivial and a find-and-replace will do the job. The old design was to pass a lot of parameter to each method like OnEntry or OnExit, for instance. Each piece of context (object instance, array of arguments, arrays of generic arguments, ...) was passed as a standalone parameter. This kind of design had serious drawbacks. The main is flexibility, i.e. forward compatibility. If I want to add a new information to the context, I have to add a new parameter... and break the public interface. Conversely, the new design often passes a single parameter, an object containing all information about the context. This makes Laos much event oriented. A join point is like an 'event' in the code and an advice is like an 'event handler'. For instance, the OnEntry method now looks like this: public override void OnEntry(MethodExecutionEventArgs eventArgs) It is really similar to event handlers written in the derived class, according to the design pattern recommended by Microsoft. I came to this idea when talking when Olaf. Aspect-oriented programming can really be seen as common event-oriented programming. It is 'just' another way to define 'events' in the code and to define event handlers. PostSharp Laos currently forces you to add the 'event handlers' at compile time, but one easily imagine extending it so that 'event handlers' can be added at runtime. What does that mean? That we get something very close to 'dynamic weaving'. But with a big difference: while event handlers can effectively be added at runtime, the events in themselves (i.e. the join points) have to be defined at compile time or at load time. That's for another time, but the current design of PostSharp Laos makes it very easy. Enjoy... and forgive the change in the public interface :-) Gael
Last week, Wang posted a very relevant remark: the integration of PostSharp in the build process of Visual Basic .NET projects simply did not work. The reason was simple: the integration was based on "compilation symbols" (or constants) defined at project-level. But VB.NET, at least in its Express edition, has no compilation symbol. I had also been alerted by Denis from DataObjects.NET that adding a compilation symbol was not always acceptable. The design problem is: how to detect that PostSharp should be executed in a project? The major constraint is performance: we cannot load each assembly, and inspect, for instance, its custom attributes. The solution Finally the solution I selected is to inspect project dependencies and to enable PostSharp if the project refers (even indirectly) the PostSharp.Public.dll assembly. Inspection of dependencies is a standard part of the build process, so there is no additional cost. Does it work always? It seems that it does. There are two major use cases of PostSharp as far as integration is concerned:
  • Explicit PostSharp project file: a psproj file is present in the C#, J# or VB.NET project file. The presence of the psproj is detected by MSBuild so the project does not need to reference PostSharp.Public.dll.
  • Automatic detection of tasks: this is the most user-friendly case. Tasks are detected automatically based on custom attributes or referenced assemblies. In order to use automatic detection, the project must refer, at least indirectly, PostSharp.Public.dll.
As you can see, in both use cases, PostSharp is properly detected. Forbidding PostSharp Now what if you refer PostSharp.Public.dll but your do not want your assembly to be post-compiled. Then you have two solutions:
  • If you are using C# or J#, you can define the NOPOSTCOMPILE compilation symbol ("constant").
  • Otherwise, you have to edit the project file (e.g. .vbproj) and add the following property:
<PropertyGroup> <SkipPostSharp>True</SkipPostSharp> </PropertyGroup>
Summary If you are a user of PostSharp, you don't have to do anything any more to 'call' PostSharp: this is done automatically. However, if you develop aspects or plugins using PostSharp and don't want your aspect libraries to be post-compiled, you have to forbid PostSharp as stated above. These features are available from revision 126 (1.0.4.126). Enjoy!
If you develop low-level transformations you would surely syntax coloring for MSIL. I have finally written a User Highlighter for the great editor PSPad (this editor is brewed in the same town as the famous Pilsner Urquel, btw). The filter is given in the new goodies folder of the www.postsharp.org website. Feel free to contribute with your own tips and utilities :-). Gael