2013-08-28 7 views
2

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

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

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

+0

Попробуйте [изолированный COM] (http://qualapps.blogspot.com.au/2007/06/isolated-com.html?m=1) – Noseratio

+0

Взаимосвязанная сборка * никогда * не зарегистрирована. Для этого требуется только COM-компонент, с которым вы взаимодействуете. Используйте рекомендуемую процедуру развертывания поставщика. –

ответ

0

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

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

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

+0

На этом этапе мы просто генерируем веб-развертывание, которое мы нажимаем непосредственно на AWS Elastic Beanstalk. Это очень просто, и я стараюсь поддерживать его «один клик» и продолжать использовать Beanstalk в качестве службы приложения, а не фактически копаться в экземплярах напрямую. –

+0

@EricLloyd, спасибо. Я все еще разрабатываю некоторый неуправляемый код, хотя большая часть его потребляется «материнскими» проектами .NET. По возможности, я предпочитаю формировать его как COM-DLL, а не делать interop-материал на C#. – Noseratio

1

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

enter image description here

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

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