Pour ce qui est des notifications, il y a les flux RSS… Je crois même que feedburner permet de s’abonner par email, mais uniquement aux posts, pas aux commentaires.

Les projets qui tombent sous la license commerciale: dataobjects.net et starcounter pour l’instant.

Un peu ennuyant que ton blog ne supporte pas les notifications par mail!

-gael

Mes essais – brefs et superficiels – s’étaient surtout concentrés sur Laos. J’avais très rapidement essayé d’utiliser PostSharp.Core pour faire des modifications de bas niveau, mais visiblement je n’ai pas creusé assez profondément. Au lieu de développer un plug-in sur PostSharp.Core, j’aurais dû utiliser ce dernier différemment. Je vais voir ce que ça donne.

Juste par curiosité, tu as des exemples de projets open source qui utilisent PostSharp.Core.dll ? Ou bien, encore moins discret : est-ce qu’il y a beaucoup de projets qui tombent sous le coup de la licence commerciale ?

Sinon, je ne crois pas prendre trop de risques en disant que tu serais le bienvenue à nos réunions parisiennes… Nous n’avons pas vraiment fait venir Jb : il nous a signalé qu’il passait sur Paris et on en a profité. Si d’aventure tu devais passer dans le coin, n’hésite pas à en faire autant :)

http://www.postsharp.org/about/architecture/

Je crois que les couches de bas-niveau de PostSharp Core et de Cecil sont quasiment identiques (puisqu’elles decalquent la specification CIL). Donc je dirais que PostSharp.Core a toutes(ou la plupart) des fonctions de l’API de Cecil pour le tissage de bas niveau. Autrement dit: on peut faire toutes les modifications que l’on veut avec PostSharp Core; on peut le faire aussi avec Cecil. Et on peut utiliser PostSharp Core comme une librairie, comme pour Cecil. La difference la plus fondamentale est dans la licence: PostSharp Core est dual GPL/commercial. Et puis, derriere JB il y a Novell, une autre difference importante.

Voir par exemple http://code.google.com/p/postsharp-user-plugins/wiki/Log4PostSharp pour un exemple de plug-in effectuant des modifications de bas niveau.

@”j’aurais aimé avoir les outils de PostSharp (intégration MSBuild, custom attributes, multicasting), et l’API de Cecil pour le tissage bas-niveau”: c’est deja le cas!

Je vois qu’il faudra que vous m’invitiez aussi ;) (mais je viens de Prague…).

Au niveau de la comparaison avec Cecil, je pense qu’on est tous plus ou moins d’accord. L’intégration au processus de build de PostSharp est particulièrement puissante, et offre une super expérience d’utilisation. Le tissage statique devient quasiment transparent (voire magique) lorsqu’on utilise Laos.

Cecil n’offre pas cette intégration, et ne compte probablement pas l’offrir, puisqu’il s’agit avant tout d’une librairie de manipulation et d’analyse d’assemblies. L’intégrer à des outils tiers comme NDepend ou Gendarme semble pertinent, l’utiliser pour faire de l’AOP telle quelle semble être un peu overkill…

Il est certainement plus intelligent de faire la comparaison avec PostSharp.Core, mais encore une fois les différences sont notables. Cecil est un outil permettant de travailler à bas niveau, mais est un outil à part entière, ce qui ne m’a pas vraiment semblé être le cas de PostSharp.Core qui ressemble plutôt à une super-fondation pour des plug-ins, spécifiques ou non. En revanche, l’intégration au process de build (entre autres) fait déjà partie de l’offre PostSharp.Core.

Dans un article précédent (que tu as peut-être vu passé), je propose une implémentation d’INotifyPropertyChanged avec Laos, mais il aurait été intéressant de créer un plugin spécifique au dessus de PostSharp.Core. Peut-être existe-il déjà, au moins à titre d’exemple ? Mes brefs essais me font penser qu’il y a déjà un bon niveau d’abstraction sur le CIL lorsqu’on utilise PostSharp.Core, alors que Cecil est directement très calée sur la structure du langage intermédiaire.

Idéalement, et c’est ce que je soulève en fin d’article, j’aurais aimé avoir les outils de PostSharp (intégration MSBuild, custom attributes, multicasting), et l’API de Cecil pour le tissage bas-niveau. Je parle toujours d’INotifyPropertyChanged, hein.

Cecil et la couche inferieure de PostSharp Core sont des produits tres similaires, qui ont ete developpes au meme moment sans contact mutuel. L’implementation de PostSharp serait tres similaire.

Au-dela de ce tronc commun, chaque outil a ses avantages. Celui de PostSharp est sans doute une plus grande “boite a outils” pour les operations de niveau intermediaire (tel que le tissage proprement parler), et l’integration dans MSBuild. Cecil a de plus grandes capacites d’analyse… et certainement d’autres avantages que je ne soupconne pas ;).

Mais je crois que, dans le cas precis de cet exemple, l’integration avec MSBuild et les custom attributs est un avantage decisif pour PostSharp. Mais pour un outil comme Gendarme, Cecil possede evidemment plus d’atouts!

-gael