Сервер и клиент DCOM написаны на .NET.

Я разрабатываю сервер DCOM в .NET 4 (VS2010, C #). Само по себе это работает нормально.

Теперь мне также нужно разработать .NET-клиент для этого DCOM-сервера, но я не могу добавить ссылку на TypeLib. Visual Studio сообщит мне, что библиотека типов была экспортирована из сборки .NET и не может быть добавлена ​​в качестве ссылки.

Ответы на этот вопрос говорят о том, что Я мог бы использовать TlbImp.exe для создания сборки оболочки, но она тоже откажется от этого:

TlbImp: ошибка TI1029: Библиотека типов MyWrapper была экспортирована из сборки CLR и не может быть повторно импортирована как сборка CLR.

Я понимаю, что с чисто .NET точки зрения использование DCOM для этого может не иметь большого смысла. Однако тот же сервер также должен быть доступен из приложений, отличных от .NET.

Я попытался преобразовать свой tlb в IDL и восстановить из него tlb, но это не обманывает Visual Studio.

Возможно, можно немного изменить IDL перед регенерацией, или есть способ принудительно использовать DCOM, даже если и сервер, и клиент написаны на .NET?


.net com dcom tlbimp
person Thorarin    schedule 22.02.2011    source источник
comment
почему вы не хотите создать чистую ссылку .Net? если вы экспортируете свою библиотеку классов в COM, это не помешает вам использовать ее в .Net.   -  person Steve B    schedule 22.02.2011
comment
Я бы сослался на сборки непосредственно в .NET или WCF, если вам нужен удаленный хостинг. Затем создайте прокси C #, который вы экспортируете как простой COM-объект, на который можно ссылаться из старых клиентов. Таким образом, у вас будет четкий путь, который нужно отрезать, когда приложения, отличные от .NET, наконец вымрут (при условии, что это ваша долгосрочная цель).   -  person Albin Sunnanbo    schedule 22.02.2011

Ответы (1)


arrow_upward
3
arrow_downward

Мне удалось заставить DCOM работать, но я не уверен, можно ли это сделать из TypeLib. Изменение IDL позволило мне импортировать библиотеку типов, но в конечном итоге во время компиляции произошел сбой (хотя Visual Studio рассматривает это как предупреждение). Возможно, все еще можно будет внести в файл еще больше изменений, но я использую гораздо более простое решение.

Все определения интерфейса для сервера DCOM были перемещены в отдельную сборку, на которую затем ссылается непосредственно клиент .NET. Это позволяет обойти проблему импорта.

Тогда доступ к серверу DCOM ничем не отличается от ожидаемого:

Guid clsId = new Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX");
Type type = Type.GetTypeFromCLSID(clsId);
IMyInterface comObject = (IMyInterface)Activator.CreateInstance(type);

Перемещение интерфейсов в отдельную сборку не является строго необходимым, но это минимизирует размер общей сборки.

person Thorarin    schedule 23.02.2011
comment
это прекрасно работает, просто не забудьте сохранить двоичный интерфейс вашего интерфейса совместимым с запущенными версиями, когда вы перекомпилируете - person Sebastian; 03.12.2011
comment
Я не совсем уверен ... здесь вы можете создавать объекты с помощью Guid, но я не думаю, что они следуют фактическому процессу создания COM. Поскольку оба являются управляемыми, CLR просто обходит всю махинацию COM и возвращает простой старый объект C #. См. Здесь: stackoverflow.com/questions/15014266/ - person schwarz; 11.09.2019