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

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

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

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

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

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

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

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

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