I have tried to use PostSharp v2 to implement some aspect oriented programming inside a SharePoint application: pretty basic stuff, like logging aspects for unhandled exceptions and such.

I noticed that PostSharp seems to have some problem at compile time if the processed assembly exists in the GAC. The build process would just fail - that means that if you need to recompile a project that uses aspects you will need to retract the solution from SharePoint, compile and then redeploy it.

I also have some random problems when using aspects inside a custom WCF service hosted on SharePoint. Including an aspect in the same dll of the service implementation seems to randomly break some of my custom services - accessing the mex endpoint just return a 401 error (not found). Notice that this seems to happen even if the service does not actually use the aspects - it is like if the sole presence of an aspect class in the code can "break" the whole assembly.

I am left wondering if I am doing something wrong or there are some known issue when using PostSharp with SharePoint. I would like to know if anybody has successfully used Postsharp on a SharePoint 2010 project. I am also open to suggestion of tested alternatives that would allow for AOP use.

NOTE: I am using PostSharp 2. I know that there is a v3 available. Do anyone know if it makes any difference?

  • 1
    I've seen AOP done in SharePoint projects using Castle Windsor - Interceptors. It doesn't mess with the compiled code, as PostSharp does. You can see several examples of aspect implementation by following this link - blog.andreloker.de/post/2009/02/20/…. Commented May 15, 2013 at 10:14
  • As far as the GAC issue, you are probably having an issue with strong naming. See this here support.sharpcrafters.com/discussions/problems/… As far as your WCF issue, you need to open your compiled assembly with ILSpy (or other tool) and see what is actually going on with your code after the aspect is applied. Do not blame the framework until you've done so. Commented May 20, 2013 at 14:18
  • 1
    Note that the problem in the ticket cited by @DustinDavis is related to delay strong-name signing. Non-delayed signing without any intervention. Commented May 20, 2013 at 14:28
  • @DustinDavis - already done this. For services that works all code is generated as expected. I will doublecheck on the broken service, but I am starting to think that this is a visual studio related problem. Based on the erratic behavior it would seems that there is something conflicting with the post-process done by PostSharp - if this is caused by some VS extension or the package process I still don't know. Commented May 20, 2013 at 15:41

1 Answer 1


PostSharp won't work properly if the assembly being processed has been installed in GAC. It needs to be uninstalled before compilation.

  • Thanks for the answer Gael, actually I had found you post here stackoverflow.com/a/1717791 so I already switched to another solution for now (will use some service extension to support log). Just to understand, are you somehow related with the PostSharp development team? Any advice on how to successfully use PostSharp in a SharePoint solution (whose assembly will end up in gac)? As now I won't need this, but it could always be useful in the future. Commented May 20, 2013 at 15:36
  • I am the lead dev of PostSharp. You can use PostSharp with SharePoint but you have to uninstall assemblies from GAC before build, which is best done in a pre-build event. Commented May 20, 2013 at 20:15
  • Nice to know. So you confirm that the only issue is the need of uninstall the assemblies from the GAC prior to a build. Ok, I will test this as soon as I have some time. Commented May 21, 2013 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.