Come posso eliminare i problemi di "DLL mancante"?

Ho realizzato alcuni giochi con Visual C ++ 2015 e OpenGL. Quando l'ho eseguito sul mio computer non c'erano problemi, ma quando l'ho eseguito su altri computer mostra che mancano alcune DLL. Voglio sapere come fare in modo che non accada la prossima volta e quali cose dovrei considerare in modo da evitare problemi di file mancanti?

È necessario installare i ridistribuibili per la versione di Visual Studio utilizzata su qualsiasi macchina che desideri eseguire gli eseguibili, ad esempio https://www.microsoft.com/en-us/download/details.aspx?id=48145 per VS2015 . Potresti anche aver bisogno di redist per DirectX o altri componenti.

Gli installatori di applicazioni generalmente installano tutti i ridistribuibili per una qualsiasi delle loro dipendenze. È possibile creare un programma di installazione di questo tipo con InnoSetup, NSIS, WIX o vari altri strumenti.

È possibile creare file eseguibili che non necessitano di ridistribuibili, ma si è quindi limitati a un sottoinsieme delle funzionalità di Windows di base, che generalmente non sono sufficienti per creare qualsiasi tipo di gioco significativo o applicazione di grandi dimensioni. Gli stessi installatori sono un esempio di applicazioni che non necessitano di dipendenze per l'esecuzione.

Uso Dependency Walker per rintracciare le DLL mancanti:

Dependency Walker è anche molto utile per la risoluzione di errori di sistema relativi al caricamento e all'esecuzione dei moduli. Dependency Walker rileva molti problemi applicativi comuni come moduli mancanti, moduli non validi, mancata corrispondenza di importazione / esportazione, errori di dipendenza circolare, tipi di moduli macchina non corrispondenti e errori di inizializzazione del modulo.

Esiste anche un'opzione di compilazione in VS per collegare staticamente le DLL:

• Il collegamento statico significa che le DLL sono incluse nel file EXE.
• Il collegamento statico aumenta la dimensione del file EXE.
• Il collegamento statico significa che questa versione della DLL verrà sempre utilizzata.
• Tuttavia, il collegamento statico significa anche che non avrai mai problemi con le DLL mancanti.

Per Visual C ++, hai alcune scelte su come gestire la ridistribuzione: esegui un EXE dal tuo programma di installazione (con diritti di amministratore), usa un modulo di unione MSM con il tuo programma di installazione MSI o persino DLL side-by-side. Vedi MSDN per i dettagli.

Il problema più grande è OpenGL. L'unica versione di OpenGL inclusa in Windows è un renderer software OpenGL 1.5. Qualsiasi altra cosa richiede l'installazione di un ICD di terze parti.

Questo è uno dei motivi per cui così tanti giochi per Windows usano DirectX invece poiché è incluso nel sistema operativo. Vedi la distribuzione di Direct3D 11 per gli sviluppatori di giochi e l' installazione non così diretta .

Disclaimer: questa è una soluzione alternativa , non una soluzione alla tua risposta, ma comunque una possibilità molto praticabile.

Se vuoi essere assolutamente sicuro che non ci siano dipendenze da VS stesso - ma ha i suoi svantaggi - nelle impostazioni di generazione del codice puoi scegliere di andare con Multi Threaded (MT) / Multi Threaded Debug (MD) (per build di debug ) anziché MT DLL (MTd) / MT Debug DLL (MDd).

Quali sono gli svantaggi?

• Aumenta le dimensioni del tuo eseguibile e il tuo binario (anche se se stai facendo un gioco questo è probabilmente trascurabile)
• compilato in questo modo non trarrà vantaggio dagli aggiornamenti delle dll di runtime. (ad es. se Microsoft rilascia VC ++ 2015 SP2, SP3, SP4 ecc.) Ma dipende da te.
• Più utilizzo della RAM (anche trascurabile) perché non riutilizzi il codice esistente / caricato (DLL)
• Devi assicurarti che tutte le librerie che colleghi siano compilate sullo stesso runtime, altrimenti il ​​collegamento potrebbe non riuscire o potrebbero verificarsi interessanti errori di runtime (probabilmente no, ma è successo a me una volta nella vita in un progetto legacy a cui è stato aggiornato l'ultimo VS)

E quali sono i professionisti?

• il tuo eseguibile non avrà dipendenze "esterne" da VS stesso (nessun requisito msvc * .dll).
• alcune persone vedono questo come un aumento delle prestazioni perché si sta eliminando l'overhead delle chiamate DLL, mentre ciò è teoricamente vero, i miglioramenti sono trascurabili nella pratica

Controlla questo link per una spiegazione più elaborata e per i guasti e le cadute che potresti incontrare utilizzando un runtime statico.

Un'altra soluzione alternativa sarebbe quella di mettere tutte le DLL richieste dove si trova il tuo binario. La tua applicazione non beneficerà degli aggiornamenti (alle librerie di runtime) ma il gioco è fatto.

La vera soluzione è quella di distribuire l'applicazione in modalità release / non debug dll (MTd) e fornire il programma di installazione ridistribuibile VC ++ corretto (e tutti gli altri programmi di installazione di librerie che è possibile utilizzare, ad esempio OpenAL, DirectX9, PhysX) e consentire all'utente di eseguirlo prima di eseguire l'applicazione (come indicato da altre risposte).

Assicurati inoltre di far sapere all'utente che potrebbe aver bisogno di aggiornare i suoi driver GPU (poiché quelli contengono più runtime anche per molte applicazioni, ad esempio OpenGL, Vulcan).

La mia soluzione era di copiare e incollare la DLL che ha causato l'errore nella cartella in cui si trova il file .sln in Visual Studio. Dopo la #includesezione, l'ho scritto #pragma comment (lib, "lost DLL name with .dll")e risolto!

Nota: ho risolto il problema riscontrato con una libreria DLL (vulkan api) di terze parti. Forse non è noto ma il 90% funzionerà in buona fortuna :)