Можно ли ссылаться на COM-DLL в управляемом проекте по пути, а не по GUID?

У меня есть управляемый (на самом деле asp.net) проект, который ссылается на COM-DLL. Прямо сейчас ссылка в .csproj выглядит так:

<COMReference Include="thenameinquestion">
  <Guid>{someguidhere}</Guid>
  <VersionMajor>1</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>tlbimp</WrapperTool>
</COMReference>

Это работает, но имеет неприятные последствия: DLL необходимо зарегистрировать на машине сборки, что означает (среди прочего) неудобно создавать несколько версий проекта, использующих разные версии DLL на одной машине сборки.

MSDN показывает задачу ResolveComReference, которая, похоже, работает правильно, но мой google-search-fu недостаточно хорош, чтобы привести реальный пример его использования. Можно ли делать то, что я хочу? Я на правильном пути?


.net msbuild com
person Dan Davies Brackett    schedule 09.07.2009    source источник

Ответы (4)


arrow_upward
9
arrow_downward

Когда вы ссылаетесь на COM-DLL, Visual Studio автоматически создает для нее сборку взаимодействия. Я считаю, что ручное управление этим процессом - отличный способ разделить сборки COM и .NET.

  1. Создайте собственную сборку взаимодействия для COM DLL, используя tlbimp.exe. См. MSDN для параметров командной строки.
  2. Ссылайтесь на свою сборку взаимодействия в проекте .NET вместо COM DLL.

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

Сборка взаимодействия может оставаться в папке без изменений до тех пор, пока (а) COM-DLL не нарушит двоичную совместимость или (б) не произойдет изменение интерфейса COM, которое фактически использует код .NET.

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

Кроме того, вам не нужно включать COM-DLL в программу установки, если вы можете предположить, что COM-DLL уже установлена ​​на целевой машине.

person Christian Hayter    schedule 25.07.2009

arrow_upward
3
arrow_downward

Как Джон Фишер уже указал, что вы ищете COM-взаимодействие без регистрации. По этому поводу уже есть много вопросов, ищите «тег под рукой» regfreecom и тесно связанный тег sxs тоже.

Однако вы легко увидите, что это может быть сложная арена, в частности:

  • Похоже, существует подтвержденная ошибка, влияющая на это в Windows XP, см. здесь. Однако исправление уже доступно, которого может быть достаточно, если вы ориентируетесь только на контролируемую среду, например ваша строительная машина.
  • Поскольку вы ориентируетесь на ASP.NET, вы должны знать, что в отличие от, например, настольное приложение - это означает, что вы не контролируете процесс хостинга, который может варьироваться в зависимости от платформы развертывания. Это означает, что будет нелегко предоставить требуемый манифест приложения для управления привязкой времени выполнения и активацией вашего COM-компонента на хосте (потенциальную альтернативу см. В следующем пункте).
  • ASP.NET 2.0, похоже, еще больше усложняет ситуацию, отказываясь от параллельной функциональности для неуправляемых компонентов. Я не нашел официального источника для этого, но автор Изоляция приложений ASP .Net 2.0 вроде бы в курсе; он предлагает по крайней мере обходной путь, который, тем не менее, выглядит сложным и потенциально хрупким.

Обобщая это, я хотел бы подчеркнуть, что «COM-взаимодействие без регистрации» может быть очень полезным и значительно упростить многие сценарии. Тем не менее, это может не упростить задачу или вообще не стать возможным для вашего конкретного сценария и среды (размещенный ASP.NET).

Удачи, дайте нам знать, удалось ли вам!

person Steffen Opel    schedule 24.07.2009

arrow_upward
2
arrow_downward

В этой статье показано, как выполнить активацию COM-компонентов без регистрации. Может быть, это поможет: http://msdn.microsoft.com/en-us/library/ms973913.aspx

person John Fisher    schedule 20.07.2009

arrow_upward
-1
arrow_downward

Похоже, это невозможно - Visual Studio будет смотреть только на GUID, упомянутый в справочнике, не обращая внимания на путь, указанный там.

У нас была аналогичная проблема с нашим сервером ежедневной сборки - COM-клиент не компилировался, если COM-сервер не был зарегистрирован. Мы просто добавили регистрацию / отмену регистрации в последовательность сборки - он регистрирует (regsv32) компонент, затем VS запускается из командной строки и сразу после завершения VS отменяет регистрацию компонента (regsvr32 -u). Работает плавно.

person sharptooth    schedule 24.07.2009