PostSharp AOP und SharePoint 2010

Question

Ich habe versucht, PostSharp V2 zu verwenden, um einige aspectorientierte Programmierung in einer SharePoint-Anwendung zu implementieren: Hübsches grundlegendes Zeug, z. B. logging Aspekte für ungehinderte Ausnahmen und z. B.

Ich bemerkte, dass PostSharp bei der Kompilierung einiges Problem zu haben scheint, wenn die verarbeitete Baugruppe im GAC vorhanden ist. Der Build-Prozess würde einfach versagen - das heißt, wenn Sie ein Projekt neu kompilieren müssen, das Aspekte verwendet, die Sie benötigen, um die Lösung von SharePoint zusammenzuleiten, kompilieren und dann erneut einzustellen.

Ich habe auch einige zufällige Probleme, wenn Sie Aspekte in einem benutzerdefinierten WCF-Dienst verwenden, der auf SharePoint gehostet wird. Einschließlich eines Aspekts in derselben DLL der Service-Implementierung scheint einige meiner benutzerdefinierten Dienste zufällig zu brechen - Zugriff auf den MEX-Endpunkt, den einfach einen 401-Fehler zurückgeben (nicht gefunden). Beachten Sie, dass dies geschehen scheint, selbst wenn der Service die Aspekte nicht tatsächlich nicht nutzt - es ist wie das einzige Anwesenheit einer Aspektklasse im Code, die die gesamte Baugruppe "brechen" kann.

Ich bin gefragt, ob ich etwas falsch mache, oder es gibt ein gewisses Problem, wenn ich ein gewisses Beispiel dafür gibt, wenn ich Postsharp mit SharePoint benutzt. Ich würde gerne wissen, ob jemand PostSharp auf einem SharePoint 2010-Projekt erfolgreich eingesetzt hat. Ich bin auch offen für den Vorschlag von getesteten Alternativen, die einen AOP-Gebrauch ermöglichen würden.

Hinweis: Ich verwende PostSharp 2. Ich weiß, dass es ein V3 gibt, das verfügbar ist. Weiß jemand, wenn es einen Unterschied macht?

Answer 1

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