Let There Be Code RSS 2.0
# Monday, May 17, 2010

image Avec un collègue nous nous sommes posés quelques questions sur le développement autour d’Office et surtout sur le déploiement des PIA (Primary Interop Assembly).

La problématique est la suivante : sur nos postes nous avons Office 2010 d’installé. Nous avons donc référencé, dans notre projet de manipulation de documents Office, les PIA d’Office 2010. Ces assemblies permettent aux applications .Net d’utiliser les fonctionnalités Office. Ceci signifie que lors du déploiement de l’application, il faut qu’Office et les PIA soient installés sur le poste client (ou sur le serveur si c’est une application web par exemple). Pour information, avec Office 2010, les PIA sont forcément installées, ce qui n’était pas le cas avec les anciennes versions. Elles ne sont d’ailleurs pas encore “redistribuable” en version 2010.

Nous venons de découvrir que sur le serveur c’est Office 2007 qui est installé, or le projet doit à terme fonctionner avec Office 2010…

Doit-on changer nos références? [Edit] Non. Lorsque l’on instancie une classe Application (pour Word par exemple), celle-ci est instanciée (en interne) en utilisant le ProgID “Word.Application” et non “Word.Application.14”. Ce ProgID est indépendant de la version d’Office installée et donc si les PIA 2007 sont installées, notre application fonctionnera.

La version installée sur le serveur est Office 2007 (version 12.0). Si nous avions référencé les PIA 12.0, après installation d’Office 2010 la redirection se ferait automatiquement. Office installe des assemblies de redirection de version dans le GAC (Policy.12.0.Microsoft.Office.Interop.XXX). Chaque assembly est accompagnée d’un fichier de configuration qui indique à la CLR que lorsque notre application lui demandera de charger une PIA 12.0, elle devra lui fournir la version 14.0.

 

Pour s’en assurer, il suffit d’ouvrir un Command Prompt et de se rendre dans le répertoire du GAC de l’assembly Policy comme indiqué ci-dessous :

image

Dans le répertoire Policy.12.0.Microsoft.Office.Interop.Word se trouvent une assembly et un fichier de config. Pour éditer le fichier de configuration il suffit depuis le command prompt de taper le nom de fichier. Ceci aura pour effet de l’ouvrir dans Visual Studio. Nous pouvons ainsi visualiser le fameux BindingRedirect de la version 12.0 vers la version 14.0 :

image

Les redirections d’Office 2003 vers 2010 sont également présentes dans le GAC.

Monday, May 17, 2010 5:18:41 PM (Romance Daylight Time, UTC+02:00)  #    Voir Commentaires
Framework .Net | VSTO
# Tuesday, December 08, 2009

Si vous avez déjà fait de la Reflection alors vous connaissez surement la méthode GetCustomAttributes(bool inherit) de la classe MemberInfo qui permet de retrouver la liste des attributs d’un membre d’un type.

 

Comme vous vous en doutez le paramètre booléen inherit permet d’indiquer au framework s’il doit rechercher également dans les types de base (du style vous avez une propriété abstraite avec des attributs dans la classe de base, et cette propriété est « overridée » dans une classe fille).

Vous écrivez le code d’appel à la méthode GetCustomAttributes, vous exécutez et vous remarquez que l’attribut de la classe de base n’est pas trouvé.

 

Un petit tour sur la msdn : http://msdn.microsoft.com/en-us/library/kff8s254.aspx  

D’après la msdn voici à quoi sert le paramètre booléen inherit : 

 

image 

 

C’est donc bien ce que nous avions compris… le booléen permet d’indiquer que l’on veut également récupérer les attributs du membre des types de base.

L’exemple donné sur la msdn confirme bien l’utilisation de ce paramètre :

 

image 

 

Là je me pose la question : c’est quoi l’arnaque ? Qu’est-ce que j’ai pu louper dans l’utilisation de cette méthode ?

 

Comme d’habitude, qui vient à mon secours dans ces moments là ? Reflector!

Et là c’est l’hallu… Je vous laisse en juger par vous même :

 

clip_image001 

 

Eh oui vous voyez comme moi, le paramètre bool inherit n’est pas utilisé… en fait ici il ne sert à rien…

Certains diront que c’est un bug. Moi je préfère dire que ce n’en ai pas un, que c’est juste une méthode qui n’est pas tout à fait terminée… chez moi j’appelle ça un bug normal, mais peu importe.

 

Heureusement il y a toujours une solution !! Il suffit d’utiliser la méthode statique System.Attribute.GetCustomAttributes(MemberInfo m, bool inherit).  

Comme vous pouvez le voir ci-dessous celle-ci fait bien ce qu’on lui demande de faire :

 

clip_image005 

 

Ce genre d’oubli me rassure tout de même, car je me dis que finalement ce sont des hommes comme vous et moi qui codent le framework.

Tuesday, December 08, 2009 5:10:02 PM (Romance Standard Time, UTC+01:00)  #    Voir Commentaires
C# | Framework .Net
Archive
<August 2010>
SunMonTueWedThuFriSat
25262728293031
1234567
891011121314
15161718192021
22232425262728
2930311234
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2010
Benoît Laut
Sign In
All Content © 2010, Benoît Laut
DasBlog theme 'Business' created by Christoph De Baene (delarou)