Регистрация сборок WiX для COM Interop

Question

Я действительно борюсь с WiX. У меня есть .NET сборки для установки, которые требуют регистрации для COM Interop, И они должны быть зарегистрированы в другой среде, которая требует вызова метода Register () в сборке .NET, которая находится в GAC. Этот метод регистрации представляет собой «черный ящик» со скрытым механизмом хранения, поэтому я не могу выполнить эту операцию декларативно.

Я понял, что декларативный подход лучше всего подходит для регистрации COM, но у меня есть две проблемы с использованием heat.exe:

1. RegAsm работает, но Heat.exe задыхается в моей сборке с сообщением:

   heat.exe: предупреждение HEAT5151: возможно не собирать данные из файла, который был ожидается сборка: C: [...] дллы.. Если этот файл не является сборкой, вы могу проигнорировать это предупреждение. Иначе, эта ошибка может быть полезна для диагностировать сбой: исключение имеет был брошен т призывание.

2. Вторичная регистрация, которую мне нужно сделать, основывается на атрибуте [ComRegisterFunction], который обычно запускает дальнейшие действия во время регистрации сборки для COM-взаимодействия. Обычно это происходит, когда сборка регистрируется RegAsm.exe или вызывается System.Runtime.InteropServices.RegistrationServices. Итак, мне нужна эта функция ComRegisterFunction в моей сборке для выполнения во время установки.

Я не против принять декларативный подход к регистрации COM (или я не возражаю, если бы тепло работало на моей сборке), но мне нужно вызвать эту функцию ComRegisterFunction как часть установки. В идеале я хотел бы взглянуть на все устанавливаемые мной исполняемые файлы, подумать о них для любых методов с атрибутом [ComRegisterFunction] и вызвать эти методы, это будет сделано после установки всех файлов.

Как мне добиться этого в WiX? Или есть другой подход? Если это имеет какое-то значение, я использую интеграцию Visual Studio с Votive со ссылками на проекты.

Answer 1

Это противоположные цели. Смысл использования декларативного подхода заключается в том, чтобы , а не , использовать Regasm.exe или Regsvr32.exe для вызова функции регистрации. Другими словами, ваш атрибутивный метод [ComRegisterFunction] не будет вызван. Вы не можете иметь оба.

Исключение, из-за которого heat.exe умирает, не является здоровым, это означает, что что-то не так с вашей функцией регистрации или классовым конструктором. Отладьте это, сделав вашу DLL стартовым проектом. Project + Properties, вкладка Debug и сделайте heat.exe автозагрузкой программы. Установите командную строку для вашей DLL. Отладка + Исключения и установите флажок Брошенный для исключений CLR, при возникновении исключения отладчик остановится.

О, и не забудьте вызвать RegistrationServices.RegisterAssembly в вашей функции регистрации. Regasm.exe больше не будет делать это автоматически, так как вы использовали атрибут.

Answer 2

Я уточню свой ответ, заявив, что правильный способ сделать это, как утверждает Ганс, - через тепло.

Однако альтернативой является использование атрибута SelfRegCost элемента File под элементом Component.

Ниже приведен пример одного из наших старых установочных комплектов, который до сих пор работал без проблем.

<File Source="..\..\External References\MSCAL.OCX" SelfRegCost="1"/>

Как и при любом ответе SO, лучше всего проверить, работает ли он в вашей ситуации, и тщательно протестировать.