Как я могу использовать сборку .net из каталога bin другого приложения, если это не в GAC?

Question

Я разрабатываю управляемое приложение на C++, которое будет взаимодействовать с продуктом другой компании. Их продукт основан на сети .net, а основной API для использования - сборка .net, называемая foo.dll.

Мое приложение требует, чтобы их продукт/ы устанавливались первым. Установка своих продуктов yeilds три различных приложения, каждый из которых в тир собственный каталог, каждый со своей директории собственный/BIN, и каждый с локальными копиями одного и того же DLL-файлы, так что вы можете найти:

C:\company\product1\bin\foo.dll 
C:\company\product2\bin\foo.dll 
C:\company\product3\bin\foo.dll 

компании рассказывал нам которые использовать .dll, и какие из них они не добавили в GAC при установке своего продукта. В настоящее время я могу запустить свое приложение, скопировав их .dll в мой каталог bin после его создания. Теперь, когда я ищу создать установщик для своего продукта, мне сложно найти элегантный способ справиться с этим. Предполагая, что их API не изменится, я должен работать с большинством версий своего продукта, если у меня есть .dll, который совпадает с тем, который использует их продукт на этом компьютере.

Очевидно, что идеальным решением было бы разместить эти сборки в GAC при установке их продукта, в частности, поскольку они делят их сами, но это вряд ли произойдет, поскольку их продукт все еще незрелый, с много более важных проблем, и то, что они делают, работает для них.

Итак, у меня возникла проблема с тем, как найти и использовать .dll Мне нужно, когда я устанавливаю свой продукт. Варианты я придумал до сих пор являются следующие:

1. Включите их .dlls в мой инсталлятор

   • Bad, потому что это блокирует меня к определенной сборки их программного обеспечения, и мы «В любом случае, получение инкрементных разработок от них будет невозможно, что не будет соответствовать их публичному выпуску.

2. Попросите моего установщика найти каталог установки и запустить gacutil.exe и все, что необходимо для размещения .dlls в GAC.

   • Плохо, потому что gacutil.exe предназначен только для разработки, а это значит, что мы должны включить его в наш установщик и установить его вместе с нашим собственным продуктом. Это также может помешать их продуктам найти сборки.

3. Попросите моего установщика найти каталог установки и скопировать DLL-файлы в мои собственные каталоги.

   • Простой, он работает, но является неэлегантным и означает, что мое приложение может сломаться, если у его продукта есть хотя бы незначительное обновление, до тех пор, пока не будут скопированы новые .dll. Я также хотел бы избежать необходимости копировать файлы.

4. Используйте код, который я нашел в http://www.roelvanlisdonk.nl/?p=713, чтобы программно добавить каталог своей установки в путь поиска .net в моем приложении во время выполнения.

   • Разумный простой, если он работает, но больше кода для обслуживания. Пока это единственный путь для автоматической загрузки DLL из их каталога.

Managed C++ и .NET все еще относительно новое для меня, большая часть моего кодирования была линукс на основе C++. Я чувствую, что это будет очень сложно, потому что другая компания неправильно управляет тем, как они используют свои сборки .net, если они хотят, чтобы другие люди могли развиваться против них.

Кто-нибудь, у кого больше опыта, имел дело с чем-то подобным и нашел способ обойти его?

Answer 1

Возможно, вы можете решить это, сделав символические ссылки на .dlls под вопросом? Таким образом, ваше приложение сможет просматривать и использовать файлы, и вы используете их физические файлы на диске. Если они обновляют файлы (исправляют некоторые ошибки), но все же поддерживают обратную совместимость, вы сможете автоматически использовать их новый код /. DLL.

Основная проблема заключается в том, что рассматриваемые сборки предназначены для использования с другими aps? Будет ли их API стабильным? Если нет, в принципе вы ничего не можете сделать.

Кроме того, если вы добавите свои каталоги на путь загрузки для поиска сборки, вы можете не преднамеренно загрузить неправильную сборку, потому что в будущем может быть несколько сборок в названии X.dll.