Question

J'ai essayé d'utiliser PostShaRP V2 pour mettre en œuvre une programmation orientée forme à l'intérieur d'une application SharePoint: des trucs assez élégants, tels que les aspects de l'exploitation forestière des exceptions non conditionnées et de tels.

J'ai remarqué que PostSharp semble avoir un problème au moment de la compilation si l'assemblage traité existe dans le GAC. Le processus de construction échouerait simplement - cela signifie que si vous devez recompiler un projet qui utilise des aspects, vous devrez rétracter la solution de SharePoint, compiler puis le redéployer.

J'ai aussi des problèmes aléatoires lorsque vous utilisez des aspects à l'intérieur d'un service WCF personnalisé hébergé sur SharePoint. Y compris un aspect dans la même dll de la mise en œuvre du service semble casser de manière aléatoire certains de mes services personnalisés - l'accès au point de terminaison MEX vient de renvoyer une erreur 401 (non trouvée). Notez que cela semble se produire même si le service n'utilise pas réellement les aspects - c'est comme si la seule présence d'une classe d'aspect dans le code peut "casser" l'ensemble de l'assemblage.

Je suis laissé se demander si je fais quelque chose de mal ou si vous utilisez un problème connu lorsque vous utilisez PostSharp avec SharePoint. J'aimerais savoir si quelqu'un a utilisé avec succès PostSharp sur un projet SharePoint 2010. Je suis également ouvert à la suggestion d'alternatives testées qui permettraient une utilisation de l'AOP.

Remarque: J'utilise PostShaRP 2. Je sais qu'il y a un V3 disponible. Est-ce que quelqu'un sache si cela fait une différence?

Était-ce utile?

La solution

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à sharepoint.stackexchange
scroll top