Как я могу избавиться от проблем с отсутствующими DLL?

Я сделал несколько игр с Visual C ++ 2015 и OpenGL. Когда я запускал его на своей машине, проблем не было, но когда я запускал его на других машинах, это показывает, что некоторые библиотеки DLL отсутствуют. Я хочу знать, как убедиться, что это не произойдет в следующий раз, и что я должен учитывать, чтобы избежать проблем с отсутствующими файлами?

Вам необходимо установить распространяемые файлы для версии Visual Studio, которую вы использовали, на любой компьютер, на котором нужно запустить исполняемые файлы, например, https://www.microsoft.com/en-us/download/details.aspx?id=48145 для VS2015. , Вам также может понадобиться переадресация для DirectX или других компонентов.

Установщики приложений, как правило, устанавливают все распространяемые файлы для любых своих зависимостей. Вы можете сделать такой установщик с помощью InnoSetup, NSIS, WIX или различных других инструментов.

Можно создавать исполняемые файлы, которые не нуждаются в каких-либо распространяемых файлах, но тогда вы ограничены подмножеством основных функциональных возможностей Windows, которых, как правило, недостаточно для создания какой-либо значимой игры или большого приложения. Сами установщики являются примером приложений, которые не нуждаются в каких-либо зависимостях для запуска.

Я использую Dependency Walker для отслеживания отсутствующих DLL:

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

В VS также есть опция времени компиляции для статической связи DLL:

• Статическое связывание означает, что библиотеки DLL включены в файл EXE.
• Статическое связывание увеличивает размер файла EXE.
• Статическое связывание означает, что эта версия DLL всегда будет использоваться.
• Однако статическое связывание также означает, что у вас никогда не будет проблем с отсутствующими DLL.

Для Visual C ++ у вас есть несколько вариантов обработки перераспределения: запустите EXE из вашего установщика (с правами администратора), используйте модуль слияния MSM с вашим установщиком MSI или даже параллельные библиотеки DLL. Смотрите MSDN для деталей.

Большая проблема - OpenGL. Единственная версия OpenGL, включенная в Windows, - это программный рендерер OpenGL 1.5. Все остальное требует установки стороннего ICD.

Это одна из причин, по которой многие игры для Windows используют DirectX, поскольку они включены в операционную систему. См. « Развертывание Direct3D 11 для разработчиков игр» и « Не такая прямая настройка» .

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

Если вы хотите быть абсолютно уверены, что нет никаких зависимостей от самой VS - но у нее есть свои недостатки - в настройках генерации кода вы можете выбрать Multi-Threaded (MT) / Multi-Threaded Debug (MD) (для отладочных сборок). ) вместо MT DLL (MTd) / MT Debug DLL (MDd).

Какие недостатки?

• Это увеличивает размер исполняемого файла и двоичного файла (хотя, если вы создаете игру, это, вероятно, незначительно)
• скомпилированные таким образом не выиграют от обновлений dll во время выполнения. (например, если Microsoft выпускает VC ++ 2015 SP2, SP3, SP4 и т. д.) Но это зависит от вас.
• Большее использование ОЗУ (также незначительное), потому что вы не используете повторно существующий / загруженный код (DLL)
• Вы должны быть уверены, что все библиотеки, на которые вы ссылаетесь, скомпилированы для одной и той же среды выполнения, иначе может произойти сбой связывания или могут возникнуть интересные ошибки времени выполнения (возможно, нет, но это случалось со мной один раз в жизни в устаревшем проекте, который был обновлен до новейшая VS)

А какие плюсы?

• Ваш исполняемый файл не будет иметь «внешних» зависимостей от самой VS (не требуется msvc * .dll).
• некоторые люди видят в этом увеличение производительности, потому что вы устраняете накладные расходы на вызовы DLL, хотя это теоретически верно, на практике улучшения незначительны

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

Другой обходной путь - поместить все необходимые библиотеки DLL туда, где находится ваш бинарный файл. Ваше приложение не получит выгоду от обновлений (для библиотек времени выполнения), но это все.

Реальным решением является распространение приложения в режиме dll выпуска / без отладки (MTd) и предоставление правильного распространяемого установщика VC ++ (и любых других установщиков библиотеки, которые вы можете использовать, например, OpenAL, DirectX9, PhysX), и позволить пользователю запустить перед запуском приложения (как указано в других ответах).

Также убедитесь, что пользователь знает, что ему / ей может понадобиться обновить драйверы графического процессора (поскольку они содержат несколько сред выполнения для многих приложений, например, OpenGL, Vulcan).

Моим решением было скопировать и вставить DLL, которая вызвала ошибку, в папку, где находится файл .sln в visual studio. После #includeраздела я написал #pragma comment (lib, "lost DLL name with .dll")и решил это!

Примечание. Я решил проблему, с которой столкнулся при работе со сторонней библиотекой (vulkan api) DLL. Может быть, это не известно, но 90% будут работать удачи :)