Понимание совместимости .NET + COM

Question

Мне нужна помощь в понимании архитектуры при вызове COM / DLL, созданных с помощью TLBIMP.EXE, из приложения .NET.Сценарий:

У меня есть библиотека DLL с именем XYZ.DLL, которая содержит методы, классы и т. Д. Теперь я могу создать оболочку .NET вокруг XYZ.DLL и получить Interop.XYZ.DLL, который я могуссылка из моего приложения .NET.

Мой первый вопрос: когда я в своем приложении .NET создаю объект из класса в Interop.XYZ.DLL и вызываю метод для этого класса, вызывается ли исходный файл XYZ.DLL?Насколько я понимаю, Interop.XYZ.DLL теперь работает как форма прокси-класса для оригинальной XYZ.DLL, и, следовательно, XYZ.DLL всегда должен присутствовать в системе для выполнения вызова?

Второй вопрос: допустим, я создал файл interop.XYZ.DLL с помощью TLBIMP.EXE.В системе, где работает мое .NET-приложение, файл XYZ.DLL исправлен / обновлен.Я предполагаю, что мое приложение будет работать до тех пор, пока те же классы / методы доступны в недавно исправленной XYZ.DLL.Или я не прав?Есть ли лучшая практика, когда приходится иметь дело с этим исправлением ссылочной библиотеки взаимодействия?

Спасибо!

С наилучшими пожеланиями, Франк

Answer 1

Ваше понимание сгенерированной Interop DLL в значительной степени верно - она ​​в основном содержит набор метаданных, которые описывают COM DLL в терминах, понятных .NET. Исходная сборка XYZ называется, поэтому должна быть зарегистрирована в целевой системе.

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

Answer 2

Первый вопрос прямо, это обертка, а не замена. Термин RCW, Runtime Callable Wrapper.

Вторая ситуация - что, если. Простое исправление ошибки, которое ничего не меняет в общедоступном интерфейсе COM-сервера, не требует никаких действий с вашей стороны, кроме проверки того, что это изменение не сломало вашу программу. Однако в COM есть жесткое правило, согласно которому для изменения публичного интерфейса необходимо использовать новый guid для интерфейса и дополнительного класса. Это очень важно, чтобы избежать DLL ада. Поскольку такое изменение может привести к очень трудному обнаружению поломки, AccessViolation не является редкостью. У вас не будет приличного способа устранить это. Такое изменение требует, чтобы вы снова запустили Tlbimp.exe, направляющие являются частью объявления библиотеки взаимодействия. И перекомпилируйте ваше приложение.