Une fois, un jeune, naïf ingénieur pensé que ce serait une bonne idée de séparer une partie de la fonctionnalité de son application dans un composant COM, écrit en C#. Visual studio avait tous les outils pour le faire, non? .NET est pratiquement fait pour cela, non? HA! Il a dit, ce sera facile. Je vais avoir décent de séparation des composants de la logique métier à l'écart de l'extrémité avant, et avec COM, je vais être en mesure de l'utiliser à partir de n'importe où! Il gaiement vérifié l' register for COM interop case à cocher dans les propriétés du projet, a exposé les classses qu'il voulait, et continua son chemin.
Oh, les essais d'un tel choix. Le jeune ingénieur, maintenant, plus expérimenté, ne serait pas le souhaitons à personne. Toutefois, la charge a été placée sur ses épaules, et le fardeau est resté lourd. Il a cherché à alléger la charge.
Le long est venu WiX, un outil de génération de fichiers de Windows Installer XML. Cette intrigue - il pu répliquer, tout simplement, la plupart du code nécessaire à un bon programme d'installation de windows fichier simplement à partir d'une poignée de fichiers de configuration. Ses vues étaient à la recherche.
Avec WiX 2.0, il pourrait générer assez facilement les fichiers nécessaires pour inscrire un C# de l'objet COM. Cela a impliqué l'utilisation de l'outil de suif. Il en ferait quelque chose comme ce qui suit:
tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs
qui pourrait alors être fixé (au début, cela a été fait manuellement, mais finalement, j'ai enregistré les étapes en un petit outil de définir le répertoire finale ref id, ID de composant, fileID, GUID et de la base de code).
Ensuite, le suivi de l'installateur et de l'installer, et il y aurait une fête joyeuse, si l'application travaillé.
Ce qui n'est pas.
Pour les jours où le jeune ingénieur versé sur les différences sur son PC de développement et celle de l'installation test, PC. "Toutes les clés de registre sont les mêmes!" Il allait s'exclamer. "Tout pour MyComExposedLibrary est inscrit, je vous le jure!"
Sauf, qu'il ne l'était pas.
À l'aube du troisième jour, après de nombreuses rosée de montagne, il a réalisé qu'il y avait un autre objet que Visual Studio a été l'inscription de son programme d'installation n'a pas été: le MyComExposedLibrary.fichier tlb.
Visual Studio, apparemment, avait été l'enregistrement de ce fichier tout au long, de la création de nouvelles sous-clés de l' HKLM\Software\Classes\Interface clé de registre, et l'enregistrement de la bibliothèque de types en HKLM\SOFTWARE\Classes\TypeLib.
Le suif a donné aucune aide, en se plaignant qu'une .tlb n'était pas un fichier, il groked. Ni le WiX 3.0 bêta - cela semblait avoir encore plus de problèmes à obtenir des choses de travail.
J'ai aussi donné de la Chaleur de l'essayer. Cela a généré de registre éléments et les éléments de classe. J'ai nettoyé la chaleur de la sortie, et ensuite de le compiler, mais j'ai reçu un autre message d'erreur: error LGHT0130 : The primary key <uuid here> is duplicated in table 'Registry'. Problème est, autant que je peux dire, que l'uuid n'existe pas réellement dans aucun de mes wxs fichiers sources. Si je change autour de la composante ref ordre dans mon élément de la fonctionnalité, un autre composant dll donne cette erreur. Depuis que j'ai succombé à l'obtention d'un WiX version 3.0 du projet pour compiler, je n'ai pas été en mesure de confirmer si oui ou non la chaleur donne le droit de sortie.
J'ai tout enlevé de l'installateur, à l'exception de celui de l'assemblée qui provoquent l'affichage de cette erreur et a essayé de compiler à nouveau. J'ai eu la même erreur même. Arrugh!
Donc, mon bon boursiers, Windows les amateurs et utilisateurs de WiX, il tombe à deux questions:
- Est un typelib quelque chose que WiX pouvez vous inscrire en natif? Si oui, comment?
- Si non, quelle est la bonne manière de l'enregistrement d'une bibliothèque de types avec un programme d'installation de windows?
Aussi, je suppose que dans une autre partie de cette, comment Visual Studio déterminer comment enregistrer la bibliothèque de types? (Edit: regarde l' article de MSDN library sur typelib enregistrement a les noms des clés nécessaires, mais j'ai encore besoin de comprendre comment obtenir l'uuid de l'. (C'est à partir de cet article de blog sur la bibliothèque de types et de COM inscription par Larry Osterman.) ) Lire un peu plus, Il peut tomber à m'inscrire ces bits manuellement, mais je ne l'espère pas...
J'ai évalué la sortie de regasm /regfile:MyDll.dll MyDll.dll. Il semble que ces sont les mêmes touches que wix génère de la dll. Regasm l'autre mode, regasm /tlb:<filename> génère et enregistre la bibliothèque de types pour l'assemblée, mais,
/regfile[:nom de fichier] Générer un fichier reg avec le nom spécifié au lieu d'enregistrer les types. Cette option ne peut pas être utilisé avec l'option /u ou /tlb options
semble que le /regfile commutateur est incompatible avec l' /tlb basculer. Khaaaaaaaan!
Mise à jour: Il semble que vous n'avez pas besoin d'inclure l' .fichier tlb. Selon ce post sur wix de la bibliothèque de types d'élément, une MSI peut créer/enregistrer en tant que partie du processus d'installation. Il s'agit de la configuration de la WiX document fait installer en obtenant le droit d'attributs.
J'ai découvert plus tard que vous pouvez obtenir le droit d'attributs à l'aide de la chaleur sur la .tlb directement! Voir ce DONC, la question pour plus d'informations.
