Когда-то молодой, наивный инженер подумал, что было бы неплохо выделить некоторые функции для своего приложения в 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, возникают два вопроса:
Кроме того, я думаю, что в качестве другой части этого, как 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 для получения дополнительной информации.
Вы должны использовать Heat (WIX 3.0), расположенный в каталоге bin используемой версии. Посмотрите на blog, мы используем его здесь, чтобы зарегистрировать весь наш COM объектов, создав фрагмент wix...
что-то вроде
heat file MyComExposedLibrary.dll -out MyComExposedLibrary.wxs
После того, как вы прочтете свое редактирование, я бы создал базовый msi с помощью wix, который устанавливает только COM-объект, посмотрите, работает ли это... тогда вы узнаете, какое поле битвы атаковать...
Недавно я столкнулся с этой проблемой, и простейшее обходное решение, которое я смог найти, следует этим шагам на машине разработки:
MyDll-2.wxs содержит элемент <Typelib>, который вы хотите скопировать и вставить внутри элемента <File>, который был сгенерирован в MyDll-1.wxs. Это даст вам полный элемент <Component>, который вы можете использовать в проекте установщика.
Чтобы извлечь COM-информацию, таллоу будет использовать regasm.exe tool, включенный в .NET framework. Вполне вероятно, что visual studio использует тот же инструмент для регистрации сборок, когда вы включаете "зарегистрироваться для COM-взаимодействия".
Разница в том, что таллоу будет использовать переключатель regasm/regfile, чтобы отправить информацию в .reg файл, а не фактически зарегистрировать сборку. К сожалению, REG файл, созданный regasm.exe, не является полным. Он пропускает записи typelib, которые он записывает в реестр во время реальной регистрации. Это может быть ошибка в regasm.
Чтобы ваш установщик работал, у вас есть три варианта:
Добавьте отсутствующие ключи реестра в список сальным выходом вручную. Сало выход должен быть отредактирован вручную и сохранены вместе с вашим другие файлы wxs в любом случае. Вы, кажется, пытаться полностью автоматически генерировать рабочий файл wxs, но я считаю, что это было никогда не была целью дизайна сала.
Используйте пользовательское действие, чтобы вызвать regasm из вашего установщика. Это немного плохо, потому что вы можете потерять некоторые из сильных транзакционных гарантий, предоставляемых движком установки Windows. Я думаю о откатах, вызванных сбоем на полпути во время установки здесь.
Избегайте регистрации вообще используя без регистрации COM. Это потребует создания файлы манифеста для обоих приложения и библиотеки COM.
Я знаю, что это старый вопрос, но другие могут найти это полезным...
После этого я обнаружил, что вы можете захватить информацию о библиотеке типов, используя tlbexp.exe, затем нагрейте как DLL, так и tlb файл. Включите выходы обоих из них в ваш проект wix, и вам должно быть хорошо идти.
tlbexp.exe dllFile.dll /out:dllFile.tlb
heat.exe dllFile.dll ...
heat.exe dllFile.tlb ...