Где установить совместно использованный DLLs в Windows
У меня есть драйвер, который может быть установлен в Windows (XP/Vista/7). К этому получают доступ через собственный C++ DLL, который сторонние приложения связывают с, и который является также Поставщиком Winsock (WSP). Это раньше устанавливалось под System32, но видевший совет не к, я изменил его для установки под ProgramFiles вместо этого.
Теперь, проблема состоит в том, что люди должны или скопировать его назад в System32 или скопировать его в каталог приложения каждый раз, когда они хотят использовать его в своих собственных приложениях, потому что Windows не будет искать каталог установки под ProgramFiles, когда приложение попытается загрузить DLL.
Я не мог найти какую-либо документацию Microsoft, обсуждающую этот вопрос, поэтому если System32 не должен использоваться затем, где должен совместно использованный DLLs быть установленным?
5 ответов
Поскольку это DLL, связанная с вашим драйвером, возможно, это не проблема, но я бы не стал пытаться поделиться этой DLL и вместо этого попытался бы заставить всех разработчиков клиентских приложений хранить свою собственную версию библиотеки DLL в своих папках приложений. Я слишком много повеселился в DLL Hell, чтобы желать еще каких-либо странных ошибок, потому что AppX перезаписал DLL старой версией, которая ломает AppY и т. д.
Собственные библиотеки DLL могут храниться как параллельные сборки. См. эту ссылку для получения дополнительной информации. Он отделен от глобального кэша сборок .NET, но использует аналогичные концепции. В этом сообщении блога также есть несколько полезных деталей о том, как библиотеки DLL разрешаются как параллельные сборки.
Где угодно на пути подойдет.
Если это будет использоваться только с вашим набором приложений (например, Qt4.dll), то в корне "c: \ program files \ my company" было бы хорошо, или 'под ней.
Если он будет использоваться другими приложениями, о которых вы не знаете (например, видеокодек), то system32 имеет смысл (вам потребуются права администратора при установке)
Фиксированное расположение файловой системы
Одна из возможностей - установить их в подкаталоге Program Files , как уже было предложено @Martin Beckett.
Местоположение переменной файловой системы, фиксированная запись в реестре
Если вы не хотите устанавливать их в фиксированном месте, вы также можете сохранить их местоположение в реестре Windows. Вы должны установить несколько ключей в HKEY_LOCAL_MACHINE \ SOFTWARE , которые ваши приложения могут прочитать, чтобы узнать, где расположены библиотеки DLL. Затем библиотеки DLL могут быть загружены во время выполнения.
P.S .: Предотвращение потерянных DLL
Вы можете пойти еще дальше и использовать реестр или другое хранилище (например, файл) для хранения информации о том, какое из ваших приложений использует какие из ваших DLL. Например:
FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll <- FooApp1, FooApp3
FooBaz.dll <- FooApp2, FooApp3
Каждый раз, когда одно из ваших приложений удаляется, оно удаляется с этой карты. После этого любой деинсталлятор может безопасно удалить DLL, которая больше не используется ни одним приложением. Этот метод похож на подсчет ссылок, и его идея состоит в том, чтобы предотвратить накопление потерянных DLL в файловой системе пользователей.
Параллельный кэш Windows. Справочная информация здесь , техническая справка здесь .
Я еще не видел, чтобы кто-то действительно делал это, кроме Microsoft. Примечательно то, что MSFT отказалась от развертывания winsxs для C / C ++ CRT и библиотек времени выполнения MFC для VS2010, что вызывало слишком много проблем. Они снова в c: \ windows \ system32. Однако управляемый эквивалент этого (GAC) набирает обороты. Наверное, лучшая поддержка инструментов.
Я почти уверен, что с большим отрывом все выбирают локальное развертывание приложения.