- In ASP.NET Web Applications, the code behind is built by Visual Studio using MSBuild.
- In ASP.NET Web Sites, the code behind is built by ASP.NET itself, or precompiled by the ASP.NET precompiler aspnet_compiler.exe.
Historically, it has always been possible to use PostSharp with ASP.NET Web Applications since PostSharp naturally integrates with any MSBuild project.
Things have been more complex with ASP.NET Web Sites. I developed an assembly post-processor that hooks into the ASP.NET build process and calls the PostSharp command-line utility just after the C# compiler. It worked – as a hack may work: sometimes, in best cases.
But there are good reasons not to use PostSharp with ASP.NET Web Sites:
- Performance issues: You probably don't want to load the CPU of your build server by an extra build step. Remember that PostSharp is about 10x slower than the C# compiler itself. If you want your web sites to start in reasonable time on web servers (where CPU is usually scarce), refrain for using PostSharp this way. Workaround: use precompiled web sites.
- Licensing issues: PostSharp is licensed for uses by developers. PostSharp does not offer a single license for use on web servers. If you're using PostSharp on a web server, you're probably breaking the license agreement. Workaround: use precompiled web sites.
- Functionality issues: Unlike ASP.NET Web Applications, which are built into a single assembly, the ASP.NET Web Sites build pipeline breaks a single web site into multiple small assemblies. This may break some PostSharp functionalities.
So I had to take a decision with this, here it is:
The use of PostSharp 2.0 with ASP.NET Web Sites is officially unsupported by SharpCrafters. Unofficially, we released the assembly post-processor on CodePlex as PostSharp4AspNet under the permissive Ms-PL license, so you can still use it at your own risks. But you have been warned.
Happy PostSharping!
-gael