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!
