Как разрешить .NET-зависимость COM-компонента?

Это мой текущий сценарий развертывания:

  • Клиентское приложение развернуто в папке A
  • DLL-библиотека COM, DLL-оболочка C++/CLI и сборка .NET развернуты в папке B.
  • DLL/сборки вместе образуют SDK, клиентское приложение является сторонним потребителем.

Вот как это должно работать:

  • Клиентское приложение запускается и создает COM-объект
  • Клиентское приложение вызывает функцию в COM-объекте
  • COM-объект перенаправляет вызов в DLL-оболочку C++/CLI
  • Функция-оболочка C++/CLI перенаправляет вызов в сборку .NET

Проблема: оболочка C++/CLI не может найти сборку .NET, и приложение аварийно завершает работу.

Решения, о которых я могу думать до сих пор:

  • Дайте сборке .NET строгое имя и разверните ее в GAC, а не в папке B.
  • Дайте клиентскому приложению файл .config и скажите ему искать сборки в папке B.
  • Добавьте в оболочку C++/CLI какую-то пользовательскую «подпрограмму разрешения», которая динамически загружает сборку .NET (что-то вроде этот ответ SO)

По разным причинам ни одно из этих решений не кажется особенно привлекательным. Знаете ли вы какой-либо другой механизм, как можно решить эту проблему? Идеальным решением было бы использование какой-либо конфигурации на стороне SDK, но, насколько я знаю, невозможно предоставить сборкам файл .config, или нет?

Поскольку я не особенно разбираюсь в .NET, я также был бы признателен за комментарии к решению «рутины распознавателя». Это то, что люди обычно делают, или это что-то экзотическое, чего следует избегать по какой-то причине?


.net c++-cli com dependency-management assembly-resolution
person herzbube    schedule 27.05.2013    source источник
comment
Почему оболочка C++/CLI не может найти сборку .NET? В чем ошибка?   -  person Simon Mourier    schedule 28.05.2013
comment
@SimonMourier Ошибка FileNotFoundException. Это происходит потому, что .NET ищет сборки только в папке A (где находится файл .exe приложения) и в GAC.   -  person herzbube    schedule 28.05.2013
comment
В оболочке C++/CLI вы можете перехватить событие AssemblyResolve: msdn.microsoft.com/en-us/library/ и указать на сборку .NET, когда среда выполнения запросит ее.   -  person Simon Mourier    schedule 28.05.2013
comment
@SimonMourier Да, это то, о чем я упоминал в обычном решении распознавателя. Я позаимствовал этот - может быть, неудачный - термин из ответа SO, на который я ссылаюсь.   -  person herzbube    schedule 28.05.2013

Ответы (1)


arrow_upward
1
arrow_downward

На мой взгляд, то, что вы назвали «программой разрешения», является лучшим решением. Поскольку ваша сборка загружается в контекст по умолчанию, пути поиска содержат текущую папку клиентского приложения, а не папку сборки. Возвращаясь к этой статье, это типичный случай использования события AppDomain.AssemblyResolve. . Я думаю, вы можете либо загрузить свою сборку в пользовательский контекст, но для меня это звучит слишком много (просто мои два цента)

надеюсь, это поможет

person loic    schedule 28.05.2013