Где установить библиотеки SDK в системе, чтобы их могли найти приложения, которым они нужны

Question

У меня есть SDK, над которым я работаю, и предыдущий разработчик просто удалил библиотеки DLL в System32 (очевидно, серьезное нарушение: см. Здесь )

Итак, если я перенесу их в \ Program Files \\ SDK (или что-то еще), как мне убедиться, что все приложения, которым нужны эти DLL, могут получить к ним доступ? И чтобы уточнить, все приложения, которые обращаются к ним, делают раннее (статическое) связывание с DLL во время компиляции, поэтому я не могу передать полный путь к ним или что-либо еще. Они должны быть в состоянии найти его только по имени файла DLL.

В том же духе, как насчет включения конкретной версии MSVCR80.dll? Все они зависят от этого, но мне нужно убедиться, что они получают конкретную версию (ту, которую я включаю). Есть идеи?

Answer 1

SDK по определению является набором для разработки. Это не патч развертывания ...

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

Причина этого в том, скажем, что вы решили сделать критическое изменение, например, исключив точку входа. Установив ваш «SDK», он может остановить работу старых программ.

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

Конечно, это может привести к появлению проблемы. Поэтому лучше всего просто установить SDK в Program Files и позволить разработчикам продуктов, которые зависят от вашего инструментария, решить, хотят ли они обновить свои версии или нет.

UPDATE

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

Answer 2

Я не могу рассказать вам о своих собственных библиотеках DLL, но вы должны никогда распространять только библиотеки Microsoft.

Вы всегда должны использовать распространяемый пакет Microsoft.

Например, если ваше приложение зависит от dll из Dev Studio 2005 с пакетом обновления 1 (SP1), вы должны распространять свое приложение с распространяемой версией Microsoft Visual Studio 2005 с пакетом обновления 1 (SP1). То же самое относится и к 2008 году. MS предоставляет установщик на основе MSI и модуль слияния для включения в собственный установщик продукта.

Answer 3

Вы спрашиваете об «DLL Hell», о чем я думал, что каждый разработчик Windows был знаком с. Порядок поиска библиотек DLL:

• каталог, из которого exex вызывал их, был загружен из
• текущий каталог
• различные каталоги Windows (как обсуждалось в предыдущем вопросе)
• каталогов в переменной PATH

Поскольку каталоги Windows должны быть исключены, у вас есть три варианта.

Answer 4

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

Вы не говорите, какую версию Windows вы используете, поскольку детали немного отличаются от того, что я помню.

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

Ваша версия самая последняя или предыдущая? Возможно, вам лучше настроить приложение для работы с этой версией или более поздней, а затем разрешить пользователям обновлять свои компьютеры по мере необходимости. Это также иллюстрирует, почему вы никогда не должны связываться с dll-файлами в \ Windows или \ Windows \ system32, так как, как указывали другие, вы можете сломать другие приложения, изменив версию этой dll.

Answer 5

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

Кроме того, вы можете развернуть библиотеки DLL в том же каталоге, что и приложение, которое зависит от них.

Я считаю, что первое лучше с точки зрения SDK - оно облегчит разработку. Но я думаю, что второе лучше, когда приложение развертывается на конечных пользователях, если только вы не ожидаете, что в одной системе может быть много потребителей, поэтому использование диска и памяти при наличии копий библиотеки DLL является непомерно большим.