Mise à jour de l'add-in Outlook basé sur ClickOnce .vsto hash change

Question

J'ai un serveur ClickOnce configuré pour héberger les plugins Outlook. Il sert automatiquement quelle que soit la version actuelle pour les machines client.

Lorsque la version du plugin change, il se met à jour parfaitement. Mais si l'un des fichiers de configuration dans la version change, je régénère le manifeste, mais il ne sera pas mis à jour car il voit le .vsto pointant vers le même numéro de version. Il ne tient pas compte du changement au DigestValue de signature numérique:

<dependency> 
    <dependentAssembly dependencyType="install" codebase="MyAddin.dll.manifest" size="12345"> 
    <assemblyIdentity name="MyAddin.dll" version="1.0.0.25" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" type="win32" /> 
     <hash> 
      <dsig:Transforms> 
       <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /> 
      </dsig:Transforms> 
      <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" /> 
      <dsig:DigestValue>********************************</dsig:DigestValue> 
     </hash> 
    <dependentAssembly> 
</dependency> 

La seule partie de l'échantillon qui change est le ********** (et évidemment la signature .vsto en bas).

Si j'essaie de modifier l'une des autres valeurs, il se plaint que la définition .vsto ne correspond pas à la définition .dll.manifest ou que la définition .dll.manifest ne correspond pas à l'assembly cible. Je ne veux pas exiger une nouvelle construction juste parce qu'un fichier .config a changé.

Comment puis-je forcer Outlook à remarquer le changement de manifeste afin qu'il s'installe réellement, au lieu de penser qu'il est exactement le même sans aucun changement?

Answer 1

J'ai finalement trouvé la question pertinente sur Stackoverflow pour quelqu'un qui essaie de faire la même chose:

How to update just one DLL in a ClickOnce installation?

Tout ce qu'il faut est en train de changer le numéro de version. Mais il doit être changé à 3 endroits, ou il se plaindra des versions non manifestes qui ne correspondent pas. Ce numéro de version NE DOIT correspondre à aucun des fichiers .dll en cours de déploiement (même s'il apparaît sous la balise "assemblyIdentity", ce qui prête à confusion). La version peut être générée à chaque fois qu'un fichier change pour forcer une mise à jour (auto-incrément, hachage, horodatage, nombre aléatoire, comme vous voulez).

Je n'ai pas pu le faire fonctionner avant parce que je mettais seulement 2 des références, tous les 3.

Première référence à ce numéro de version se trouve au sommet du manifeste d'application:

<asmv1:assemblyIdentity name="MyAddin.dll" version="w.x.y.z" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" type="win32" /> 

la deuxième place est au sommet du manifeste deploy:

<asmv1:assemblyIdentity name="MyAddin.vsto" version="w.x.y.z" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" xmlns="urn:schemas-microsoft-com:asm.v1" /> 

Et la troisième place est à l'intérieur du manifeste deploy:

<dependentAssembly dependencyType="install" codebase="MyAddin.dll.manifest" size="12345"> 
    <assemblyIdentity name="MyAddin.dll" version="w.x.y.z" publicKeyToken="1234567890abcdef" language="neutral" processorArchitecture="msil" type="win32" />