Créer un installeur (MSI)

[(gile)]

Salut,

 

[Olivier Eckmann]

Bonjour Gilles,

 

C'est limpide, très bien expliqué.

 

Merci pour ce tuto

 

Olivier

 

 

 

[Olivier Eckmann]

Re,

 

J'aurais une question. Est-ce que le productcode du projet Installer doit/peut être le même que celui indiqué dans le contents.xml? Idem pour la version 1.0.0?

 

Merci

Olivier

[(gile)]

Salut,

 

Non, si j'ai bien compris, le ProductCode spécifié dans Visual Studio est celui de l'installeur (utilisé par Windows, pour la désinstallation par exemple) et celui spécifié dans PackageContents.xml est celui du plugin (utilisé par Autodesk) ; idem pour les versions.

Le UpgradeCode est défini une fois pour toutes et ne doit pas être modifié dans les deux cas.

 

Personnellement , j'ai toujours utilisé des ProductCodes différents pour l'installeur et le plugin mais j'essaye de conserver les mêmes numéros de version pour m'y retrouver.

 

Ce à quoi il faut faire attention, c'est de bien changer le ProductCode de l'installeur et celui du plugin à chaque nouvelle version pour que l'installation de la nouvelle version écrase automatiquement l'ancienne. Dans Visual Studio, quand on change le numéro de version, Visual Studio propose automatiquement de changer le ProductCode. Dans le fichier PackageContents.xml, il faut faire ces changements "à la main".

[(gile)]

Re,

 

Après quelques investigations dans la base de registre, je pense ne pas avoir dit trop de bêtises dans le message ci-dessus, néanmoins, j'ai noté que chez Autodesk, quand ils construisent les installeurs pour les plugins d'Exchange Apps, ils utilisent les mêmes ProductCode et UpgradeCode pour l'installeur et le plugin.

 

Donc, en conclusion, il semble qu'on puisse indifféremment utiliser les mêmes code ou des codes différents (en tout cas, mon expérience le confirme).

Utiliser les mêmes codes est peut-être une meilleure pratique (évident si on automatise le processus de génération d'installeur comme doit le faire Autodesk) ne serait-ce qu'en incitant à modifier le ProductCode d'un côté quand on l'a modifié de l'autre.

[Olivier Eckmann]

Salut,

 

Merci pour ces investigations, je vais partir sur le même pour le plug-in et l'installer, ce sera plus simple pour moi.

 

Olivier

[Manu.Net]

Merci Gilles pour cette vidéo très claire,

 

Manu

[PhilBat]

Bonjour,

j'ai le cas d'une solution avec 61 projets et en deux versions x32 et x64.

Créer un installeur dans ce cas de figure me semble moins évident.

Avez-vous un exemple similaire ?

Autre question, est-il possible de désactiver le chargement d'un bundle au lancement

d'AutoCAD ?

J'ai essayé de modifier la variable 'APPAUTOLOAD' avec la valeur '0', mais cela ne change rien.

Merci d'avance.

Philippe.

[(gile)]

Salut,

 

Si tu utilises le mécanisme AutoLoader (bundle), le choix de créer ou pas un installeur n'a rien à voir avec le nombre de projets et dépend simplement de la manière dont on veut déployer le plugin sur différents postes. Dans ce cas, l'installeur ne fait rien d'autre que de placer le dossier .bundle dans le répertoire ApplicationPlugins.

Comme je le disais ici :

Aucune obligation de faire un MSI, coller le dossier .bundle dans un dossier ApplicationPlugins est suffisant à condition d'avoir les droits d'accès au dossier suffisants.

Si je fais des installeurs c'est, d'une part pour ne pas avoir de problème avec le "blocage" de fichiers .zip, .dll, etc. téléchargés et d'autre part pour simplifier les mises à jour.

Si la création de versions différenciées 32 et 64 bits est une nécessité (ça ne l'est généralement pas avec .NET), tu peux aussi créer un installeur pour chacune des versions (32 et 64 bits).

 

Dans tous les cas, avec le mécanisme AutoLoader, c'est le fichier PackageContents.xml qui gère complètement le chargement des DLLs (quelle DLL est chargée et comment).

Si tu ne veux pas que toutes les DLLs soient chargées au démarrage d'AutoCAD, il faut jouer avec l'attribut "LoadReasons" et utiliser LoadOnCommandInvocation="True" et LoadOnAutoCADStartup="False".

 

C'est si tu n'utilises pas le mécanisme AutoLoader, qu'un installeur est nécessaire, mais il devra faire, avec des "actions personnalisées" tout ce que fait le fichier PackageContents.xml (enregistrements dans la base de registre des DLLs, des chemins de support, etc).