TLB для управляемой сборки .NET без Regsrv32 во время развертывания

У меня есть TLB, который был предоставлен как часть стороннего API. Я использовал TLBIMP.exe для создания оболочки сборки DLL. Однако во время разработки оказалось, что для использования сборки требуется регистрация в regsvr32.

Однако это не проблема во время разработки; Я использую управляемые экземпляры в производстве, и регистрация DLL вручную будет болезненной, если не невозможной, при развертывании. Есть ли способ использовать управляемую сборку DLL, не требуя регистрации во время развертывания?

Я читал в Интернете и нашел некоторую литературу по COM без регистрации с использованием app.manifest. Может ли это быть жизнеспособным решением?


.net c# com-interop regsvr32 typelib
person Alex Hatcher    schedule 28.08.2013    source источник
comment
Попробуйте использовать изолированный COM.   -  person noseratio    schedule 29.08.2013
comment
Сборка взаимодействия никогда не регистрируется. Это требуется только COM-компоненту, с которым вы взаимодействуете. Используйте рекомендуемую поставщиком процедуру развертывания.   -  person Hans Passant    schedule 29.08.2013

Ответы (2)


arrow_upward
1
arrow_downward

Если библиотека типов также встроена в COM-DLL стороннего производителя, как и должно быть, Изолированный COM действительно можно использовать для этого (вы можете проверить это с помощью OleView). Использование COM DLL таким образом довольно просто с VS2010/2012. DLL должна быть зарегистрирована на машине разработки. Затем вы просто добавите его как ссылку на свой проект .NET и включите его свойства Embed Interop Types и Isolated:

введите здесь описание изображения

Сборка взаимодействия будет объединена с потребляющей сборкой .NET, и вам нужно будет только убедиться, что COM DLL, сборка .NET и сгенерированные файлы .manifest копируются вместе при развертывании.

Очень важно учитывать модель COM-квартиры вашего клиентского приложения. У вас не должно возникнуть проблем с клиентом STA. Однако для модели MTA маршаллер на основе библиотеки типов по умолчанию может не работать для COM-объектов, созданных изолированной библиотекой DLL (подробнее об этом -c-sharp-console-project">здесь). Если DLL поставляется с реализованным кодом прокси/заглушки COM, это также не должно быть проблемой.

person noseratio    schedule 29.08.2013

arrow_upward
0
arrow_downward

К сожалению нет. Ваша целевая DLL является COM-DLL и поэтому должна быть зарегистрирована на каждом компьютере, на котором она развернута. Хорошая новость, если вы создаете установочный пакет для развертывания, заключается в том, что большинство достойных наборов инструментов установщика должны поддерживать регистрацию COM из коробки. Проверьте документацию вашего установщика.

Если вы выполняете развертывание через xcopy на большом количестве устройств, я бы сказал, что пришло время переосмыслить вашу стратегию. Единственное утешение, которое вы можете принять, заключается в том, что COM-DLL необходимо зарегистрировать только один раз для каждой коробки для каждой развернутой версии. Но тем не менее, xcopy установки в наши дни, как правило, плохая идея.

ОБНОВЛЕНИЕ: я исправлен — я голосую за Noseratio. Показывает, как мало я уделяю внимания COM-интеграции в наши дни.

person Eric Lloyd    schedule 28.08.2013
comment
На данном этапе мы просто создаем веб-развертывание, которое отправляем непосредственно в AWS Elastic Beanstalk. Это чрезвычайно просто, и я пытаюсь сохранить аспект «одного щелчка» и продолжать использовать Beanstalk в качестве службы приложений, а не копаться в экземплярах напрямую. - person Alex Hatcher; 29.08.2013
comment
@ ЭрикЛлойд, спасибо. Я все еще разрабатываю неуправляемый код, хотя большая его часть используется материнскими проектами .NET. Там, где это возможно, я предпочитаю формировать его как COM-DLL, а не выполнять взаимодействие на C#. - person noseratio; 30.08.2013