Code partagé entre deux extensions VSTO de perspectives

Question

Nous avons une situation où nous aurons deux compléments Outlook VSTO qui commencent tous les deux par du code partagé commun, mais le code partagé sera probablement différent au fil du temps. Idéalement, nous aimerions restructurer les compléments pour intégrer le code commun dans une DLL partagée séparée, mais pour des raisons non techniques, ce n'est pas une option pour le moment. Quels problèmes anticipez-vous si les deux compléments sont déployés sur la même instance de perspectives? Voyez-vous des problèmes surgir parce qu'il y aurait deux classes avec le même nom et le même espace de noms, mais avec des définitions différentes chargées par les deux compléments différents sur la même instance de perspectives? L'un des compléments doit également appeler un formulaire dans l'autre complément. Pensez-vous que ce sera un problème avec les différences dans le code commun?

En supposant que nous réussissions à restructurer les compléments pour séparer une DLL avec tout le code commun, Outlook aura-t-il un problème avec les différentes versions de la même DLL déployées par les deux compléments différents?

Answer 1

Mon projet actuel avait effectué un partage de code similaire entre les compléments VSTO pour Word. Pour l'instant, nous utilisons des références à l'autre projet avec "copy local" au moment de la compilation mais nous aimerions changer cela pour référencer le code partagé hors du GAC afin que nous soyons libérés du scénario de construction du composant partagé nécessitant une reconstruction de tous les projets qui en dépendent. Si toutes vos DLL de bibliothèque partagée sont "copy local" pendant la construction, vous ne devriez pas avoir de conflits de nom/espace de noms - mais vous devrez reconstruire le complément à chaque fois que votre code de bibliothèque partagée change. Si vous souhaitez que les générations soient gérées séparément, créez un complément qui servira de bibliothèque, et installez une copie de lui-même dans le GAC afin que d'autres compléments puissent l'utiliser. J'ai inclus des liens qui montrent comment appeler du code à partir d'autres compléments. En pratique, je l'ai trouvé un peu loufoque à cause de VSTO étant .Net sur le code natif de Microsoft Office.

Références:

• Sharing code between add-ins
• Calling code between add-ins
• Getting a VSTO add-in into GAC with an MSI installer