Когда-то молодой, наивный инженер подумал, что было бы неплохо выделить некоторые функции для своего приложения в COM-компоненте, написанном на С#. У Visual Studio были все инструменты для этого, не так ли?.NET был практически сделан для этого, не так ли? ХА! Он сказал, что это будет легко. У меня будет достойное разделение компонентов, оставление бизнес-логики в стороне от интерфейса, а с COM я смогу использовать его из любого места! Он весело проверил флажок register for COM interop в свойствах проекта, разоблачил классы, которые хотел, и пошел дальше.
О, испытания такого выбора сделаны. Теперь молодой инженер, более опытный, не пожелал бы этого никому. Однако бремя было возложено на его плечи, и бремя оставалось тяжелым. Он хотел облегчить нагрузку.
В дополнение к WiX, инструмент для создания файлов установщика Windows из XML. Это заинтриговало его - он мог бы довольно просто копировать большую часть кода, необходимого для правильного файла установки Windows, просто из нескольких файлов конфигурации. Его взгляды смотрели вверх.
С WiX 2.0 он мог легко генерировать файлы, необходимые для регистрации COM-объекта С#. Это связано с использованием инструментального жира. Он сделал бы что-то вроде следующего:
tallow -c -nologo MyComExposedLibrary.dll > MyComExposedLibrary.wxs
который затем был бы исправлен (сначала это было сделано вручную, но в конце концов я записал шаги в небольшой набор инструментов, который включает в себя конечный идентификатор ref ref, идентификатор компонента, fileID, GUID и базу кода).
Затем последующий установщик установит, и будет радостное празднование, если приложение работает.
Что это не так.
В течение многих дней молодой инженер выливал различия на своем ПК разработки и на компьютер с тестовой установкой. Msgstr "Все ключи реестра одинаковы!" Он воскликнул. "Все для MyComExposedLibrary зарегистрировано, я клянусь!"
Кроме того, это не так.
На заре третьего дня, после многих горных росов, он понял, что есть еще один объект, который Visual Studio регистрировал, что его установщик не был: файл MyComExposedLibrary.tlb.
Visual Studio, судя по всему, регистрировала этот файл все время, создавая дополнительные подразделы в разделе реестра HKLM\Software\Classes\Interface и регистрируя typelib в HKLM\SOFTWARE\Classes\TypeLib.
Tallow не помог, жалуясь, что .tlb не был файлом, который он пытался. Также не было бета-версии WiX 3.0 - у нее было еще больше проблем, связанных с работой.
Я также попросил Heat. Это создало элементы реестра и элементы класса. Я очистил тепловую мощность, а затем пошел компилировать его, но получил другую ошибку: error LGHT0130 : The primary key <uuid here> is duplicated in table 'Registry'. Проблема заключается, насколько я могу судить, что uuid фактически не существует ни в одном из моих исходных файлов wxs. Если я изменю порядок заказа компонента в моем элементе функции, это даст другой компонент dll. Поскольку мне не удалось получить версию проекта WiX 3.0 для компиляции, я не смог подтвердить, дает ли тепло правильный результат.
Я удалил все из установщика, кроме одной из сборщиков, которые вызывают появление этой ошибки, и снова попытались выполнить компиляцию. У меня такая же ошибка. Arrugh!
Итак, мои хорошие ребята, энтузиасты Windows и пользователи WiX, возникают два вопроса:
- Является ли typelib чем-то, что WiX может зарегистрировать изначально? Если да, то как?
- Если нет, то какой способ регистрации typelib с установщиком окон?
Кроме того, я думаю, что в качестве другой части этого, как Visual Studio определяет, как зарегистрировать typelib? (Edit: выглядит В статье библиотеки MSDN на регистрацию typelib есть имена необходимых ключей, но мне все же нужно выяснить, как получить uuid's. (Это от это сообщение в блоге о регистрации typelib и COM Ларри Остерманом.)) Читаю немного больше, Может быть, для меня для регистрации этих бит вручную, но я надеюсь, что...
Я оценил вывод из regasm /regfile:MyDll.dll MyDll.dll. Похоже, что это те же ключи, что и wix для dll. Другой режим regasm, regasm /tlb:<filename> генерирует и регистрирует typelib для сборки, но
/regfile [: FileName] Создайте файл reg с указанным именем вместо регистрации типов. Этот параметр не может использоваться с параметрами /u или/tlb
Кажется, переключатель /regfile несовместим с ключом /tlb. Khaaaaaaaan!
Дальнейшее обновление:Похоже, вам не нужно включать файл .tlb. В соответствии с этим сообщением о файле wix typelib, MSI может создать/зарегистрировать это как часть процесса установки. Все сводится к настройке документа WiX, чтобы фактически установить его, получив нужные атрибуты.
Я узнал позже, что вы можете получить правильные атрибуты, используя тепло непосредственно на .tlb! См. этот вопрос SO для получения дополнительной информации.
