Partager via

Configuration du serveur de publication

  • Article

Un fichier de configuration d’éditeur redirige globalement les applications et les assemblys qui dépendent d’une version d’un assembly côte à côte pour utiliser une autre version du même assembly. Cela permet aux applications et aux assemblys d’utiliser l’assembly mis à jour sans avoir à reconstruire toutes les applications affectées.

Les fichiers de configuration du serveur de publication peuvent être fournis par l’éditeur d’un assembly lors de l’émission d’une nouvelle version de l’assembly avec des correctifs de bogues ou des mises à jour de sécurité compatibles. La version mise à jour doit être entièrement rétrocompatible. Un fichier de configuration d’éditeur ne doit jamais être utilisé pour ajouter de nouvelles fonctionnalités, sauf si la mise à jour est entièrement rétrocompatible. Les fichiers de configuration publisher ne doivent jamais être utilisés pour incrémenter la version principale ou mineure d’un assembly. Par exemple, ne redirigez pas l’assembly version 6.0.0.0 vers 7.0.0.0 ou vers 6.1.0.0.

Les fichiers de configuration du serveur de publication doivent uniquement être émis par l’éditeur de l’assembly. Les développeurs d’assemblys doivent signer les assemblys côte à côte partagés et les fichiers de configuration de l’éditeur. Utilisez la même clé pour signer l’assembly et les fichiers de configuration de l’éditeur associés. Les fichiers de configuration publisher doivent être signés à l’aide des mêmes outils que pour les assemblys. Consultez Exemple de signature d’assembly et Création de fichiers et catalogues signés.

En règle générale, la nouvelle version d’un assembly et le fichier de configuration de l’éditeur associé sont installés dans une mise à jour du Service Pack. Les fichiers de configuration du serveur de publication ne doivent jamais être fournis avec des applications en tant que redistribuables, car l’installation d’un fichier de configuration d’éditeur redirige globalement les assemblys sur le système. Si l’assembly mis à jour est fourni en tant que redistribuable, l’éditeur doit fournir les deux éléments suivants.

  • Package Windows Installer (fichier .msi) qui inclut la nouvelle version de l’assembly avec la configuration de l’éditeur. Il peut être installé en tant que Service Pack ou QFE, car dans ce cas, le client a choisi de mettre à jour globalement le système. Cette version du package ne doit jamais être installée par les applications.
  • Un module de fusion Windows Installer (fichier .msm) qui inclut uniquement la nouvelle version de l’assembly. Cette version peut être incluse dans les applications.

Les applications nécessitant une version minimale de l’assembly doivent indiquer leur dépendance à la version minimale. Si la version minimale n’est pas disponible sur un système, l’application ne parvient pas à démarrer. S’il est disponible en tant que redistribuable, il doit être inclus dans le programme d’installation de l’application.

Par exemple, l’installation du fichier de configuration de l’éditeur suivant redirige la liaison de la version 2.0.0.0 de Microsoft.Windows.SampleAssembly vers la version 2.0.1.0. Cela ajoute une nouvelle stratégie, nommée 1.1.0.0.Policy, sous %systemDrive%\windows\winsxs\policies\x86_policy.2.0.Microsoft.Windows.SampleAssembly_75e377300ab7b886_x-ww_<hashvalue>.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity type="win32-policy" publicKeyToken="0000000000000000" name="policy.2.0.Microsoft.Windows.SampleAssembly" version="1.1.0.0" processorArchitecture="x86"/>
   <dependency>
      <dependentAssembly>
         <assemblyIdentity type="win32" name="Microsoft.Windows.SampleAssembly"  processorArchitecture="x86" publicKeyToken="75e377300ab7b886"/>
         <bindingRedirect oldVersion="2.0.0.0" newVersion="2.0.1.0"/>
      </dependentAssembly>
   </dependency>
</assembly>

L’installation du fichier de configuration d’éditeur suivant pour le même assembly redirige la liaison de la version 2.0.0.0 de Microsoft.Windows.SampleAssembly vers la version 2.0.3.0. Cela ajoute une autre stratégie, nommée 2.1.0.0.Policy, sous %systemDrive%\windows\winsxs\policies\x86_policy.2.0.Microsoft.Windows.SampleAssembly_75e377300ab7b886_x-ww_<hashvalue>.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity type="win32-policy" publicKeyToken="0000000000000000" name="policy.2.0.Microsoft.Windows.SampleAssembly" version="2.1.0.0" processorArchitecture="x86"/>
   <dependency>
      <dependentAssembly>
         <assemblyIdentity type="win32" name="Microsoft.Windows.SampleAssembly"  processorArchitecture="x86" publicKeyToken="75e377300ab7b886"/>
         <bindingRedirect oldVersion="2.0.0.0" newVersion="2.0.3.0"/>
      </dependentAssembly>
   </dependency>
</assembly>