Force l'installation du GAC avant d'exécuter l'action personnalisée .NET?

Question

J'utilise un projet d'installation et de déploiement de VS 2008 pour déployer une application mixte gérée/non gérée. J'ai rencontré des problèmes lors de l'enregistrement des DLL en mode mixte à l'aide de la propriété d'inscription intégrée (valeur énumérée "vsdraCOM" de la propriété "Register"). Pour contourner le problème, j'ai ajouté un assembly d'installation .NET personnalisé (avec une classe dérive de System.Configuration.Install.Installer.) Je suis certain que cette classe est en cours d'exécution et qu'un certain nombre d'opérations réussissent à installer et désinstaller via le code dans cet assembly, y compris l'exécution du point d'entrée Dll (Un) RegisterServer d'un certain nombre d'assemblys .

Toutefois, une DLL ne réussit pas à s'enregistrer. C'est la seule DLL qui dépend de certains assemblys redistribuables tiers qui veulent être installés sur le GAC. Ces assemblages sont installés sur le GAC grâce à la prise en charge intégrée des projets d'installation et de déploiement de VS 2008, et je sais que cela fonctionne. J'ai confirmé que ce qui se passe est que l'action personnalisée est en cours d'exécution avant que le programme d'installation exécute l'installation GAC.

Ouf. Donc ma question est, y at-il un moyen de forcer le programme d'installation à exécuter l'installation du GAC avant d'exécuter l'action personnalisée? Est-il possible d'utiliser la propriété "Condition" de l'action personnalisée pour le faire? Sinon, quelle est ma meilleure alternative? Capture les entrées de registre à partir de la DLL et les ajoute aux paramètres de registre pour le programme d'installation (n'aime pas cela parce que quelqu'un peut ajouter de nouveaux serveurs COM à la classe à l'avenir)? Utilisation du code .NET pour installer manuellement l'assembly dans le GAC (ne savez pas encore comment le faire)?

Merci,

Dave

Answer 1

Les projets d'installation que vous pouvez créer dans Visual Studio sont très limitées. Il permet uniquement de planifier des actions personnalisées à 4 points. Cependant, MSI permet de planifier des actions personnalisées à tout moment du processus, avec certaines restrictions sur ce qu'elles peuvent faire.

Ma première solution est d'arrêter d'utiliser Visual Studio 2008 comme outil de développement d'installation. L'équipe de Visual Studio a tenté d'abstraire toute la complexité de la création d'une installation. Cependant, dans le processus, ils ont également enlevé toute la flexibilité de MSI. Wix, InstallShield ou Wise sont des produits bien meilleurs pour tout sauf pour les installations simples. J'ai commencé à utiliser Visual Studio pour nos installations et cela a fini par être trop dur. Il y avait toujours une solution de rechange à mettre en œuvre et ses effets secondaires à traiter.

Si vous ne pouvez pas changer de technologie, vous devrez apprendre à modifier manuellement le fichier MSI résultant. Dans votre cas, vous devrez modifier la table InstallExecuteSequence, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx. Vous pouvez le faire manuellement via Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx ou via l'API MSI http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx. Assurez-vous de télécharger Orca et exécutez les scripts de validation contre votre installation. Les scripts signalent de nombreux problèmes que la réparation vous fera économiser d'innombrables heures lors du déploiement sur les machines client.