Як я можу позбутися від "відсутніх проблем з 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, чого, як правило, недостатньо для створення будь-якої змістовної гри або великого застосування. Самі інсталятори є прикладом програм, яким не потрібні ніякі залежності.

Я використовую Denderpend 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. Все інше вимагає встановлення стороннього МКБ.

Це одна з причин, чому так багато ігор 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 у візуальній студії. Після #includeрозділу я написав #pragma comment (lib, "lost DLL name with .dll")і вирішив!

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