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 :

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 :

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

Parmi les nombreuses nouveautés du développement d’addin VSTO, nous retrouvons bien évidemment le Ribbon, qui est maintenant disponible depuis l’Explorer d’Outlook 2010. A l’ombre de cette grande nouveauté, d’autres font leur apparition mais passent un peu inaperçu.  

Dans le développement d’addin VSTO pour Outlook 2010, il est aujourd’hui possible de définir des icones personnalisées pour certains répertoires.  Comme vous pouvez le voir sur l’image ci-contre, j’ai défini une icône custom pour 2 de mes répertoires. La classe MAPIFolder possède maintenant une méthode SetCustomIcon qui prend en paramètre une instance de la classe StdPicture :

Afin d’obtenir une instance de type StdPicture à partir d’un objet de type Bitmap (ou Image), il faut créer une classe qui hérite de AxHost. Cette classe est un wrapper de contrôle ActiveX et possède une méthode statique (et protected) qui se nomme GetIPictureDispFromPicture :

Le tour est joué, il n’y a plus qu’à faire appel à la méthode SetCustomIcon :

Cette semaine j’ai publié une nouvelle version de BOWIE.

La précédente version était une beta qui fonctionnait pour TFS 2010 RC, celle-ci supporte TFS 2010 RTM.

En plus de supporter TFS 2010 RTM, cette nouvelle version corrige les bugs qui avaient été remontés sur la Beta. Au niveau des nouveautés, vous pouvez maintenant gérer vos alertes comme dans Visual Studio :

BOWIE 2010 fonctionne pour TFS 2008/2010 et Outlook 2007. Il est compatible Outlook 2010. Cependant je travaille actuellement sur une nouvelle version qui fonctionnera exclusivement sur Outlook 2010 afin de bien s’intégrer au nouveau Ribbon.

Hier je me suis attaqué à l’upgrade de BOWIE sur la version RC de TFS 2010, qui sera disponible sur Codeplex en fin de semaine.

Pour cette occasion, voici une interview menée par Patrice Lamarche et qui présente les fonctionnalités de BOWIE 2010.

Si vous ne connaissez pas encore cet addin TFS pour Outlook c’est l’occasion de le découvrir en images!

Comme l’indique clairement le titre, la version 2010 de mon addin TFS pour Outlook est disponible en version beta. Il fonctionne pour Outlook 2007 et 2010 et TFS 2008 et 2010 beta 2. Quelques uns de mes collègues me servent actuellement de beta testeur (merci Lio et Io).

Vous retrouverez sur la page d’accueil du projet codeplex la liste des fonctionnalités disponibles.

Pour le télécharger, ça se passe par là ---> http://bowie.codeplex.com

N’hésitez pas à m’envoyer vos remarques, suggestions, bugs…

Quoi de mieux pour démarrer mon blog que de présenter mon addin TFS pour Outlook ?

Cet outil, disponible sur Codeplex à cette adresse http://bowie.codeplex.com, permet d’intégrer TFS à Outlook.

Pour l’instant l’outil fonctionne avec Outlook 2007 et 2010 et TFS 2008. Je travaille actuellement sur une nouvelle version afin d’intégrer de nouvelles fonctionnalités et d’être compatible avec TFS 2010. Cette nouvelle version devrait être disponible fin Novembre et fonctionnera donc sur la Beta 2 de TFS 2010. N’hésitez pas à me contacter si vous avez des idées d’évolutions !

Voici la liste des fonctionnalités disponible actuellement :

Dans le Ribbon d’un email reçu :

• Créer un nouveau Work Item depuis l’email
• Attacher l’email à un Work Item existant (formats html, txt, msg…)
• Télécharger les pièces jointes de l’email vers une librairie de documents d’un Team Project
• Retrouver les Work Items attachés à ce mail

Dans le Ribbon d’un email que vous rédigez :

• Ajouter en pièces jointes des documents depuis les librairies de documents d’un Team Project
• Ajouter en pièces jointes des reports d’un Team Project (formats pdf, excel, tiff…)
• Ajouter les infos de Work Items dans le corps du mail

Dans le menu principal d’Outlook:

• Menu Team –> Gérer mes favoris : permet d’ajouter les Team Projects avec lesquels vous voulez travailler et de définir un Team Project par défaut

Depuis le menu contextuel d’un répertoire de mails:

• Définissez un lien entre un répertoire de mail et un Team Project. Ce lien permet de créer automatiquement des Work Items lorsque l’on déplace un mail dans ce répertoire. Vous pouvez définir le type de Work Item à créer, le mapping des champs, et d’autres paramètres comme par exemple attacher le mail ou ses pièces jointes au work item. L’image ci-dessous présente la fenêtre de paramétrage. L’onglet “WSS Portal” est une nouvelle fonctionnalité qui ne sera présente que pour la prochaine version.