Jak pozbyć się problemów z „brakującą biblioteką DLL”?

Zrobiłem kilka gier za pomocą Visual C ++ 2015 i OpenGL. Kiedy uruchomiłem go na moim komputerze, nie było problemu, ale kiedy uruchomiłem go na innych komputerach, pokazuje, że brakuje niektórych bibliotek DLL. Chcę wiedzieć, jak się upewnić, że nie powtórzy się to następnym razem, i co powinienem wziąć pod uwagę, aby uniknąć problemów z brakiem plików?

Musisz zainstalować składniki redystrybucyjne dla wersji programu Visual Studio używanego na dowolnym komputerze, który chce uruchomić pliki wykonywalne, np. Https://www.microsoft.com/en-us/download/details.aspx?id=48145 dla VS2015 . Możesz także potrzebować redystów dla DirectX lub innych komponentów.

Instalatorzy aplikacji zazwyczaj instalują wszystkie składniki redystrybucyjne dla dowolnej z ich zależności. Możesz utworzyć taki instalator za pomocą InnoSetup, NSIS, WIX lub różnych innych narzędzi.

Możliwe jest tworzenie plików wykonywalnych, które nie wymagają żadnych składników redystrybucyjnych, ale jesteś ograniczony do podzbioru podstawowych funkcji systemu Windows, co zasadniczo nie wystarcza, aby stworzyć jakąkolwiek sensowną grę lub dużą aplikację. Same instalatory są przykładem aplikacji, które nie wymagają żadnych zależności do uruchomienia.

Używam Dependency Walker do śledzenia brakujących bibliotek DLL:

Dependency Walker jest również bardzo przydatny do rozwiązywania problemów z błędami systemowymi związanymi z ładowaniem i wykonywaniem modułów. Zależność Walker wykrywa wiele typowych problemów z aplikacjami, takich jak brakujące moduły, nieprawidłowe moduły, niedopasowania importu / eksportu, błędy zależności cyklicznej, niedopasowane typy modułów maszyn i niepowodzenia inicjalizacji modułów.

Istnieje również opcja czasu kompilacji w VS do statycznego łączenia bibliotek DLL:

• Łączenie statyczne oznacza, że ​​biblioteki DLL są zawarte w pliku EXE.
• Łączenie statyczne zwiększa rozmiar pliku EXE.
• Łączenie statyczne oznacza, że ​​ta wersja biblioteki DLL będzie zawsze używana.
• Łączenie statyczne oznacza jednak, że nigdy nie będziesz mieć problemu z brakującymi bibliotekami DLL.

W przypadku Visual C ++ masz kilka możliwości obsługi redystrybucji: uruchom EXE z instalatora (z uprawnieniami administratora), użyj modułu scalającego MSM z instalatorem MSI, a nawet bibliotek DLL. Szczegóły w MSDN .

Większy problem to OpenGL. Jedyną wersją OpenGL, która jest dołączona do systemu Windows, jest renderer oprogramowania OpenGL 1.5. Cokolwiek innego wymaga zainstalowania zewnętrznego urządzenia ICD.

Jest to jeden z powodów, dla których tak wiele gier Windows używa DirectX, ponieważ jest on dołączony do systemu operacyjnego. Zobacz Wdrażanie Direct3D 11 dla twórców gier i Nie taka bezpośrednia konfiguracja .

Zastrzeżenie: Jest to obejście , nie rozwiązanie twojej odpowiedzi, ale bardzo realna możliwość.

Jeśli chcesz mieć absolutną pewność, że nie ma żadnych zależności od samego VS - ale ma to swoje wady - w ustawieniach generowania kodu możesz wybrać opcję Multi Threaded (MT) / Multi Threaded Debug (MD) (dla kompilacji debugowania ) zamiast MT DLL (MTd) / MT Debug DLL (MDd).

Jakie są wady?

• Zwiększa rozmiar pliku wykonywalnego i plik binarny (chociaż przy tworzeniu gry jest to prawdopodobnie nieistotne)
• skompilowane w ten sposób nie skorzystają z aktualizacji bibliotek DLL środowiska uruchomieniowego. (np. jeśli Microsoft wyda VC ++ 2015 SP2, SP3, SP4 itp.) Ale to zależy od Ciebie.
• Większe użycie pamięci RAM (również nieistotne), ponieważ nie używasz ponownie istniejącego / załadowanego kodu (DLL)
• Musisz upewnić się, że wszystkie biblioteki, które łączysz, są skompilowane z tym samym środowiskiem wykonawczym, w przeciwnym razie połączenie może się nie powieść lub mogą wystąpić interesujące błędy w czasie wykonywania (prawdopodobnie nie, ale zdarzało mi się to raz w życiu w starszym projekcie, który został zaktualizowany do najnowszy VS)

A jakie są zalety?

• twój plik wykonywalny nie będzie miał „zewnętrznych” zależności od samego VS (bez wymagania msvc * .dll).
• niektóre osoby postrzegają to jako wzrost wydajności, ponieważ eliminuje się narzut wywołania DLL, podczas gdy jest to teoretycznie prawda, ulepszenia są znikome w praktyce

Sprawdź ten link, aby uzyskać bardziej szczegółowe wyjaśnienie oraz pułapki i problemy, które możesz napotkać przy użyciu statycznego środowiska uruchomieniowego.

Innym obejściem byłoby umieszczenie wszystkich wymaganych bibliotek DLL tam, gdzie jest twój plik binarny. Twoja aplikacja nie skorzysta z aktualizacji (bibliotek wykonawczych), ale to wszystko.

Prawdziwym rozwiązaniem jest dystrybucja aplikacji w trybie dll wydania / braku debugowania (MTd) i dostarczenie poprawnego redystrybucyjnego instalatora VC ++ (oraz wszelkich innych instalatorów bibliotek, których możesz użyć, np. OpenAL, DirectX9, PhysX) i umożliwienie użytkownikowi uruchomienia tego przed uruchomieniem aplikacji (jak wskazały inne odpowiedzi).

Upewnij się również, że użytkownik wie, że może zaktualizować sterowniki GPU (ponieważ zawierają one wiele środowisk wykonawczych dla wielu aplikacji, np. OpenGL, Vulcan).

Moim rozwiązaniem było skopiowanie i wklejenie biblioteki DLL, która spowodowała błąd, do folderu, w którym znajduje się plik .sln w Visual Studio. Po #includesekcji napisałem #pragma comment (lib, "lost DLL name with .dll")i rozwiązałem!

Uwaga: Rozwiązałem problem z biblioteką DLL innej firmy (vulkan api). Może nie wiadomo, ale 90% zadziała, powodzenia :)