Avec le WiX installé, réexécutez la préparation __. Fichier bat pour régénérer le projet d'installation ainsi que le principal projet de plug-in. Construisez le projet plugin, puis construisez le projet d'installation nommé quelque chose comme {YourPlugin} _WiXInstaller. Le msi sera placé dans le répertoire \ build \ bin \ {YourPlugin} \ {Configuration} de Firebreath ({Configuration} est Debug, Release, etc).
Il est pas nécessaire de modifier le fichier WiX, sauf si vous voulez vraiment changer un paramètre spécifique. Une chose que je peux penser est de changer l'installation par utilisateur par défaut à tous les utilisateurs. Par utilisateur est généralement mieux car il évite les problèmes de l'UAC.
Déploiement à l'utilisateur est un peu plus compliqué. Pour la plupart des navigateurs, l'utilisateur doit enregistrer & exécuter le msi. Sur Internet Explorer, vous pouvez déclarer un objet dans le corps HTML et pointez le code de base à une URL contenant le plugin:
<object id="pluginid" type="application/x-yourplugin" width="0" height="0" codebase="/YourPlugin.msi" >
<param name="onload" value="pluginLoaded" />
</object>
Cependant la sécurité IE9 semble bloquer MSI ici. Cela fonctionne si la DLL du plugin est utilisée (codebase = "/ YourPlugin.dll"). Cette méthode d'installation automatique ne fonctionne que dans IE avec des binaires signés (à moins que les options de sécurité d'Internet Explorer ne soient trop poussées). Espérons que a discussion thread on the MSI security issue donnera quelques réponses.
Mise à jour: Comme hinted by Richard/taxilian, un MSI doit être emballé dans un fichier CAB pour que IE pour l'installer. Obtenir le bon INF et créer le CAB prend quelques additional steps as documented by RB. Et pour ajouter encore une autre ride, Vista/Win7 n'autorise pas l'INF à appeler un binaire en dehors du fichier CAB, donc une application de lancement de stub doit être utilisée (voir this thread et un exemple de code posté par Roey vers le bas).