Does anyone out there has used Postsharp AOP framework in production environment? Are there any pitfalls? In order to do some logging etc, can Postsharp be used in conjunction with log4net ?
Any tutorials on using Postsharp with Web Apps and/or log4net will be highly appreciated.
Thanks In Advance.
We tried using post sharp for one or two things, the problem was that it blew the build times out way too long. If you are using CI, and have a frequent checkin methodology, you better have a damn good build server and workstation machines.
Apparently .net 4.0 is going to have a bunch of compiler hooks to make things like AOP easier to do. Our final conclusion was to wait for that.
I use Postsharp and I like it. It save's me a lot of duplicated code I had to add otherwise.
I did not need any advanced features for log4Net and google is enough to find out how it works. It just does the job. I haven't seen any disadvantages so far.
For Postsharp, the getting started guide on the website, the blog and browsing through the source is enough. A major disadvantage is the increased build time. I hate waiting for my computer to do work. It takes about 8 seconds to press ctrl-shift-b in visual studio (on a fast PC) for the +-60K loc solution with 2 projects using the postsharp build action. If you can, try to use Postsharp in the least amount of projects possible.
When you really don't want to use postsharp, you can create a solution with 20 projects and add the post-build command to every one of them. The build time will be long enough to annoy the rest of the team.
Personally I will probably keep on using Postsharp for future projects. The advantages overrule the extra build time.
I and one other teammate use PostSharp in different ways on several projects that are in production and have been for months. For example, in one case, I use it to log method parameter values in case of an Exception. PostSharp Laos (included in PostSharp) is an easy to use way of injecting method calls (on method entry, exit and on exceptions, for example) and you could easily add log calls to log4net registered loggers.
It has increased build times, enough to slightly change my build habits, but certainly not too much for the benefits it provides, IMO. While writing code, you may wish to exclude it from your local build, which is easy enough to do, so you can continue to build frequently and quickly, then include it on your build server etc.
Here's a good tutorial from Gael (the PostSharp creator)... though it is old, it's nice to see it a run-through. There is really no difference in using it in a console, winforms, WPF or WebApp that I've encountered so far. link text
I would also say that once you've figured out how to add Laos aspects to a project, repeating the exercise is very easy. And there is a relationship between how many assemblies/classes you apply the aspects to and how much time PostSharp adds to your build. So you can even control the build time issues a bit.
As for the code, I am very very impressed with how well PostSharp works... it has never screwed up a build, made an assembly invalid or otherwise messed up code. And I have even used it in ASP.NET apps, with code coverage and performance instrumentation (so it's played nicely with MS' Assembly instrumentation tools).
All in all, I would def. recommend you try it out for your log4net requirements.
We do use PostSharp in production, both for 3.5 runtime and for Silverlight runtime. To speed up builds a bit you can use /m: switch for msbuild (google for parallel builds with msbuild). They also promise to speed it up dramatically in the upcoming release.
According to the PostSharp Community Survey, a lot of companies use PostSharp in production. The frustrating thing is that they refuse to be identified :-(.