Ma solution
Ok, donc après avoir beaucoup tapé ma tête contre le mur -- en découvrant que les propriétés msbuild, les conditions, et les inclusions de projet ne fonctionnent pas pour/dans la section ProjectExtensions, j'ai trouvé un hack supplémentaire qui fait que mon .csproj fonctionne dans Visual Studio 2013 [Update 3] que le développeur ait Office 2010 ou Office 2013 installé (c'est détaillé dans le deuxième point ci-dessous -- qui n'est pas requis pour le même comportement dans VS 2010, YMMV pour VS 2012).
Pour que votre projet fonctionne de cette façon, vous devez procéder comme suit trois des choses :
-
Modifiez à la main votre fichier .csproj et trouvez toutes les références de l'assemblage d'interopérabilité bureautique - assurez-vous que la version est définie comme étant la version "14.0.0.0" (par opposition à "15.0.0.0") et que l'élément enfant "SpecificVersion" est présent et défini comme étant "False".
-
Dans le cadre du projet \ProjectExtensions\VisualStudio\FlavorProperties\ProjectProperties trouve la paire attribut/valeur "OfficeVersion" et la supprime (de sorte que l'attribut qui se lit comme suit OfficeVersion="14.0" -- supprimer cela). -- Laissez tous les autres 14.0s intacts, si quelque chose a été changé en 15.0, rétrogradez-le en 14.0 (et encore une fois, si c'est une référence, mettez SpecificVersion à false). -- Ne vous souciez pas de changer les GUIDs, laissez-les tels quels !
-
À ce stade, la solution s'ouvrira et se compilera sur les machines qui exécutent Visual Studio 2013, qu'elles aient Office 2010 ou Office 2013. -- Mais elle ne sera pas commencer la solution sur des machines exécutant Office 2013. Pour corriger cela :
- Ouvrir regedit et naviguer dans HKLM \Software\Microsoft\Office\
- Exportez l'ensemble de la branche 15.0 dans un fichier .reg.
- Ouvrez le fichier dans le bloc-notes et remplacez toutes les occurrences de "15.0" dans le chemin du registre par "14.0".
- Enregistrez à nouveau le fichier (assurez-vous de l'enregistrer en unicode).
- Importez le fichier et redémarrez Visual Studio. -- Cela vous permettra de commencer à déboguer avec Office 2013.
Une autre chose à garder à l'esprit -- surtout si vous utilisez EmbedInteropTypes, assurez-vous que lorsque vous faites votre build de release / publication, vous le faites à partir d'une machine avec Office 2010 (et non 2013) installé, de sorte que l'assemblage publié est construit contre les bibliothèques spécifiques d'Office 2010. -- Cela vous permettra de maintenir la compatibilité ascendante et descendante entre les deux versions.
Encore une fois, cela a fonctionné pour moi pour un complément de Word - pour un complément d'Excel YMMV.
Réponse originale (peut contenir des détails utiles pour les autres)
J'ai mentionné dans les commentaires ci-dessus que j'ai le problème opposé - VS 2013 Update 3 met à jour de force mes projets si l'utilisateur a installé Office 2013.
Vous pouvez essayer d'installer VS 2013 Update 3 (même temporairement, disons dans une VM) et la dernière version de VSTO 2012 / 2013, et d'ouvrir le projet, cela devrait forcer la mise à jour du vôtre également. Je sais que vous utilisez Excel, et que j'utilise Word, mais la section qu'il met à jour :
Ancien .csproj XML :
<Project ...>
...
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{BAA0C2D2-18E2-41B9-852F-F413020CAA33}">
<ProjectProperties HostName="Word" HostPackage="{20A848B8-E01F-4801-962E-25DB0FF57389}" OfficeVersion="14.0" VstxVersion="4.0" ApplicationType="Word" Language="cs" TemplatesPath="VSTOTemplates" DebugInfoExeName="#Software\Microsoft\Office\14.0\Word\InstallRoot\Path#WINWORD.EXE" DebugInfoCommandLine="/w" AddItemTemplatesGuid="{51063C3A-E220-4D12-8922-BDA915ACD783}" />
<Host Name="Word"... />
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>
...
</Project>
Nouveau .csproj XML :
<Project ...>
...
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{BAA0C2D2-18E2-41B9-852F-F413020CAA33}">
<ProjectProperties HostName="Word" HostPackage="{29A7B9D7-A7F1-4328-8EF0-6B2D1A56B2C1}" OfficeVersion="15.0" VstxVersion="4.0" ApplicationType="Word" Language="cs" TemplatesPath="VSTOTemplates" DebugInfoExeName="#Software\Microsoft\Office\15.0\Word\InstallRoot\Path#WINWORD.EXE" DebugInfoCommandLine="/w" AddItemTemplatesGuid="{51063C3A-E220-4D12-8922-BDA915ACD783}" />
<Host Name="Word"... />
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>
...
</Project>
Il me semble que les deux choses qui ont changé sont :
-
Le chemin d'accès au registre de 14.0 à 15.0 (ce qui, dans VS 2010, était facile à contourner - il suffisait de créer un chemin d'accès au registre correspondant à 14.0 qui pointait vers l'endroit où vous aviez installé Word 2013 et tout fonctionnait bien).
-
L'ID CLS du paquet hôte. Je ne sais pas ce qu'ils sont pour Excel, mais vous pouvez probablement les chercher. -- Je préfère ne pas modifier l'ID CLS du projet archivé, afin que les développeurs qui développent et testent le projet avec Word 2010 puissent continuer à le faire, tout comme ceux qui développent et testent avec Word 2013.
En outre, il semble que deux références aient été mises à jour de 14.0 à 15.0. Il s'agit d'une erreur majeure, car nous ne voulons construire et intégrer que les types d'interopérabilité 2010 (ceux-ci fonctionnent bien en 2013, mais nous ne voulons pas accéder accidentellement à une propriété réservée à 2013 qui ne fonctionnerait pas en 2010...).
Les deux références qui ont été mises à jour sont "Microsoft.Office.Interop.Word" et "Office".
Edit : Il semble que je puisse définir ces deux références à SpecificVersion : False, puis modifier manuellement le fichier XML pour les ramener à "14.0.0.0" (la version semble être grisée dans le menu normal).
