Можно ли ссылаться на 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 не был достаточно хорош для придумайте фактический пример его использования. Можно ли делать то, что я хочу? Я на правильном пути?

Ответ 1

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

Создайте собственную сборку взаимодействия для COM-библиотеки с помощью tlbimp.exe. См. MSDN для параметров командной строки.
Ссылка на вашу сборку interop в .NET-проекте вместо COM-библиотеки.

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

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

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

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

Ответ 2

Как Джон Фишер указал, что вы ищете Без регистрации COM Interop. Есть много вопросов по этому поводу, ищите "тег под рукой" regfreecom и тесно связанный тэг sxs.

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

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

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

Удачи, пожалуйста, сообщите нам, преуспели ли вы!

Ответ 3

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

Ответ 4

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

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