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

Question

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

Answer 1

Когда вы ссылаетесь на 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 уже будет установлена ​​на целевой машине.

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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