Subscribe to our newsletter for release news and a monthly status report.
You can unsubscribe at any time.
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.
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:
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 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).