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
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.
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.
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:
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 (188.8.131.52).
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 :-).
I've just put online a
that shows how to create a Trace aspect using PostSharp Laos. I know, people that read my blog probably already master this trivial example...
Comments are welcome. A question I ask to myself is: what is better? A Flash tutorial or a screen capture video with comments in my Belgian accent? If you have an opinion about this, please share it :-)