Como posso me livrar de problemas de "DLL ausente"?

Eu fiz alguns jogos com o Visual C ++ 2015 e OpenGL. Quando o executei na minha máquina, não havia problema, mas quando o executei em outras máquinas, isso mostra que algumas DLLs estão ausentes. Quero saber como garantir que isso não aconteça na próxima vez e que coisas devo considerar para evitar problemas de falta de arquivo?

Você precisa instalar os redistribuíveis para a versão do Visual Studio usada em qualquer máquina que queira executar os executáveis, por exemplo, https://www.microsoft.com/en-us/download/details.aspx?id=48145 para o VS2015 . Você também pode precisar de redists para o DirectX ou outros componentes.

Os instaladores de aplicativos geralmente instalam todos os redistribuíveis para qualquer uma de suas dependências. Você pode fazer esse instalador com o InnoSetup, NSIS, WIX ou várias outras ferramentas.

É possível criar executáveis ​​que não precisam de redistribuíveis, mas você fica limitado a um subconjunto da funcionalidade principal do Windows, que geralmente não é suficiente para criar qualquer tipo de jogo significativo ou aplicativo grande. Os próprios instaladores são um exemplo de aplicativos que não precisam de nenhuma dependência para serem executados.

Eu uso o Dependency Walker para rastrear DLLs ausentes:

O Walker de Dependência também é muito útil para solucionar erros do sistema relacionados ao carregamento e execução de módulos. O Dependency Walker detecta muitos problemas comuns de aplicativos, como módulos ausentes, módulos inválidos, incompatibilidades de importação / exportação, erros de dependência circular, tipos de módulos incompatíveis de máquina e falhas de inicialização do módulo.

Há também uma opção de tempo de compilação no VS para vincular estaticamente as DLLs:

• Vincular estaticamente significa que as DLLs estão incluídas no arquivo EXE.
• Vincular estaticamente aumenta o tamanho do arquivo EXE.
• Vincular estaticamente significa que esta versão da DLL sempre será usada.
• No entanto, vincular estaticamente também significa que você nunca terá um problema com a falta de DLL.

Para o Visual C ++, você tem algumas opções de como lidar com a redistribuição: execute um EXE do seu instalador (com direitos de administrador), use um módulo de mesclagem MSM com o instalador do MSI ou até mesmo DLLs lado a lado. Consulte o MSDN para obter detalhes.

O maior problema é o OpenGL. A única versão do OpenGL incluída no Windows é um renderizador de software OpenGL 1.5. Qualquer outra coisa requer que um ICD de terceiros seja instalado.

Esse é um dos motivos pelos quais muitos jogos do Windows usam o DirectX, pois ele está incluído no sistema operacional. Consulte Implantação do Direct3D 11 para desenvolvedores de jogos e instalação não tão direta .

Isenção de responsabilidade: Esta é uma solução alternativa , não uma solução para sua resposta, mas ainda assim, uma possibilidade muito viável.

Se você quiser ter certeza absoluta de que não há dependências do próprio VS - mas ele possui suas próprias desvantagens - nas configurações de geração de código, você pode optar por usar Multi Threaded (MT) / Multi Threaded Debug (MD) (para compilações de depuração ) em vez de MT DLL (MTd) / MT Debug DLL (MDd).

Quais são as desvantagens?

• Aumenta seu tamanho de executável e seu binário (embora se você estiver criando um jogo, isso provavelmente é insignificante)
• compilado dessa maneira não se beneficiará das atualizações das DLLs de tempo de execução. (por exemplo, se a Microsoft lançar o VC ++ 2015 SP2, SP3, SP4 etc.) Mas isso é com você.
• Mais uso de RAM (também insignificante) porque você não reutiliza o código existente / carregado (DLLs)
• Você precisa garantir que todas as bibliotecas vinculadas sejam compiladas no mesmo tempo de execução, caso contrário, a vinculação poderá falhar ou poderão ocorrer erros interessantes (provavelmente não, mas isso aconteceu comigo uma vez na vida em um projeto legado que foi atualizado para o mais novo VS)

E quais são os profissionais?

• seu executável não terá dependências "externas" do próprio VS (nenhum requisito msvc * .dll).
• algumas pessoas vêem isso como um aumento de desempenho porque você está eliminando a sobrecarga de chamadas de DLL, enquanto isso é teoricamente verdade, as melhorias são negligenciáveis ​​na prática

Verifique este link para obter uma explicação mais elaborada e para os problemas e falhas que você pode encontrar ao usar um tempo de execução estático.

Outra solução alternativa seria colocar todas as DLLs necessárias onde está o seu binário. Seu aplicativo não se beneficiará de atualizações (para as bibliotecas de tempo de execução), mas é isso.

A solução real é distribuir o aplicativo no modo DLL de liberação / sem depuração (MTd) e fornecer o instalador redistribuível correto do VC ++ (e quaisquer outros instaladores de biblioteca que você possa usar, por exemplo, OpenAL, DirectX9, PhysX), e deixar o usuário executar esse antes de executar seu aplicativo (como outras respostas indicadas).

Além disso, certifique-se de informar ao usuário que ele / ela precisa atualizar seus drivers de GPU (pois eles também contêm vários tempos de execução para muitos aplicativos, por exemplo, OpenGL, Vulcan).

Minha solução foi copiar e colar a DLL que causou o erro na pasta em que o arquivo .sln está localizado no visual studio. Após a #includeseção, escrevi #pragma comment (lib, "lost DLL name with .dll")e resolvi!

Nota: eu resolvi o problema que encontrei com uma DLL de biblioteca de terceiros (API do vulkan). Talvez não seja conhecido, mas 90% dará boa sorte :)