12 08 2014
Descobrindo qual dll está faltando no deployment da sua aplicação
Olá caro(a) leitor(a)!
Você já passou pela situação de fazer um deployment manual (copiando os arquivos do build manualmente para o computador destino) e alguma dll estava faltando?
Windows está procurando uma solução para o problema… Mas ele nunca encontra uma!
Se isso já aconteceu, você sabe que o Windows não te ajuda em nada para descobrir qual dll está faltando no deployment. Primeiramente, a mensagem de erro (acima) não dá nenhuma dica de qual arquivo está faltando. Além disso, se olharmos no log do Windows, acabamos também não encontrando algo de útil que nos ajude a descobrir qual é a tal dependência que não conseguiu ser resolvida.
Olha o Windows falando pra gente: “Desculpa aí, não consegui carregar todas as dependências dessa aplicação. Quer saber qual arquivo está faltando? Hmm, não sei. Se vira aí”
Quando a lista de dependências da sua aplicação ainda é pequena, fica fácil de olhar nas referências da aplicação e lembrar qual é a dll que esquecemos de copiar. Porém, a partir do momento que sua aplicação cresce e as dependências aumentam (principalmente quando utilizamos bibliotecas de terceiros como DevExpress, Telerik, etc), fica cada vez mais difícil de adivinhar qual arquivo está faltando para distribuir.
Por muitas vezes eu ficava horas analisando o pacote de deployment para identificar o arquivo que estava faltando. Até que eu descobri uma ferramenta que pode nos ajudar com esse problema: fuslogvw.exe (mas isso é nome de ferramenta??). E sabe o que é o melhor de tudo? Se você tem o Visual Studio instalado, você já tem essa ferramenta, uma vez que ela é instalada automaticamente junto com o Windows SDK.
Para encontrar essa ferramenta, considerando que você tenha o Visual Studio 2013 instalado, vá até o seguinte diretório:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
(caso você tenha outras versões do Visual Studio, o diretório pode variar, principalmente a parte “v8.1a”)
Se você quer analisar um deployment na sua própria máquina de desenvolvedor, basta abrir o executável “fuslogvw.exe” que se encontra nessa pasta. Porém, normalmente queremos analisar o deployment em uma outra máquina, que muito provavelmente não tem o Visual Studio instalado e por isso você não encontrará essa pasta “Microsoft SDKs“. Nesse caso, basta copiar esse executável de um computador que tenha o Visual Studio instalado até o computador destino, juntamente com o arquivo “flogvwrc.dll” presente no subdiretório “1033”.
No computador onde você queira testar o deployment, abra esse executável como administrador, e você verá esta simples tela:
Clique em “Settings” e configure a ferramenta da seguinte forma:
(“c:\templog\” pode ser substituído com algum diretório onde você queira salvar os logs dessa ferramenta – só não esqueça da barra final no caminho da pasta de log, senão você receberá um erro parecido com “Custom log path must not be relative. And it must be an existing directory. Please reset custom log path”)
Agora execute sua aplicação com problema, depois clique em “Refresh” na ferramenta e veja a mágica acontecer:
Pronto! Agora você já sabe quais dlls estão faltando no seu deployment. Muito mais fácil do que ficar investigando manualmente, não?
Essa dica eu encontrei depois de eu ter pesquisado no StackOverflow e ter encontrado essa questão. E então eu acabei chegando neste artigo do blog “Emil’s Lost & Find Archive” e na documentação do MSDN sobre o fuslogvw.
Espero que tenham gostado. Até o próximo artigo!
André Lima
Dica rápida: Cancelando o tempo de reinicialização do Windows Update Instalando o Windows através de um flash drive USB (pen drive)
[…] Essa é uma grande desvantagem do InnoSetup. Nós, desenvolvedores, precisamos escolher todas as dependências da aplicação nessa etapa, enquanto que as outras ferramentas demonstradas nesse artigo conseguem detectar automaticamente os arquivos necessários. De qualquer forma, caso o seu instalador gerado com o InnoSetup não funcione devido a alguma dll faltando, confira este outro artigo que mostra como descobrir qual dll está faltando no deployment. […]
Muito boa essa dica André, não conhecia esse procedimento que com certeza irá me ajudar em algum momento.
Valeu pelo comentário, Bruno! Sem dúvida.. Esse procedimento já me salvou em várias situações.. Espero que te ajude também!
Abraço!
André Lima
Onde clica pra agradecer?!
Onde clica pra agradecer?
Mano, é incrível como seus tutoriais fazem parte da nossa realidade, já sofri muito com isso, valeu mesmo! Vc é o cara!!!
Tenho que tirar um tempo pra fuçar seu site, tem mta coisa boa é cada dia acho uma nova!
Fala Tony!
Valeu demais pelo comentário! Fico muito feliz que o artigo tenha te ajudado.. Esse tipo de agradecimento é o que mais me motiva a produzir mais conteúdo ainda..
Grande abraço!
André Lima
Andre,
peço sua ajuda para entender o que está dando de errado algo que não tem solução há dias. Desenvolvi um sistema com Visual Studio 2015 e Firebird que funciona bem na minha máquina. Quando faço o deplay (implantar) em qualquer outra máquina, aparece a mensagem “SuaAplicação parou de funcionar” (igual a primeira imagem deste post). Seguindo as instruções do seu artigo, tentei usar C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\FUSLOGVW.exe com a DLL que está no diretório 1033. O programa não deixa criar um arquivo de log dizendo: “Custom log path must not be relative. And it must be an existing directory. Please reset custom log path”. Certifiquei-me que o diretório existe e continua negando criar o arquivo. Como uso windows 7, substitui “v8.1A” pelo “v7.0A” como recomendou observar a versão (o tamanho dos arquivos FUSLOGVW.exe é diferente). Enfim, não consigo saber se falta DLL, não sei a razão do programa não funcionar.
Agradeço se puder ajudar.
Abraço!
Olá Murilo, obrigado pelo comentário!
Consegui reproduzir o erro que você mencionou e descobri o que estava causando ele.. Você precisa colocar uma barra no final do caminho do log.. Então, ao invés de “c:\templog“, você precisa colocar “c:\templog\“..
Já corrigi o artigo explicando esse problema, veja só:
Abraço!
André Lima
Grande Andre,
muito obrigado pela imensa colaboração. Vi o log e descobri que tenho que colocar a mesma DLL do Firebird que é gerada quando faço o build do projeto (não pode ser de outra data). Preciso confirmar se é isso mesmo, no entanto, tive sucesso através do seu blog.
Sucesso, obrigado e obrigado!
Abraço!
Olá Murilo!
Que bom que funcionou.. Fico feliz que você tenha conseguido resolver o seu problema com a ajuda deste artigo!
Grande abraço!
André Lima
Nao consegui, pelo menos não no Windows XP, dá que o aplicativo não é um aplicativo Win32 válido.
Olá novamente Carlos!
Estranho.. Talvez alguma dependência desse aplicativo não esteja disponível no Windows XP.. Não sei te dizer o que pode ser.. Mas, de qualquer forma, pelo que você me falou por e-mail, você já conseguiu fazer o Report Viewer funcionar no Windows XP, né?
Abraço!
André Lima
Boa noite André. Obrigado mais uma vez pela suas dicas incríveis e salvadoras. Gostaria de saber se pode me esclarecer uma duvida pois pesquisando não encontrei muita coisa. Usando seu procedimento o executável me retorna esse erro.
*** Entrada de Log do Fichário de Assembly (30/07/2018 @ 01:43:27) ***
A operação falhou.
Resultado da associação: hr = 0x80004005. Erro não especificado
Gerenciador de assemblies carregado de: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Executando sob executável C:\Users\HP\Desktop\Debug\WpfApp1.exe
— Segue um log detalhado de erros.
=== Informações sobre estado pré-associação ===
LOG: DisplayName = System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Users/HP/Desktop/Debug/
LOG: PrivatePath inicial = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = WpfApp1.exe
Chamando assembly: System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
Attempting to use native image C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Drawing\af10d278d6c02fda2196fccad0624e15\System.Drawing.ni.dll.
Rejecting native image because dependency C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll is not native
o outro erro
*** Entrada de Log do Fichário de Assembly (30/07/2018 @ 01:43:27) ***
A operação falhou.
Resultado da associação: hr = 0x80004005. Erro não especificado
Gerenciador de assemblies carregado de: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Executando sob executável C:\Users\HP\Desktop\Debug\WpfApp1.exe
— Segue um log detalhado de erros.
=== Informações sobre estado pré-associação ===
LOG: DisplayName = System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
(Fully-specified)
LOG: Appbase = file:///C:/Users/HP/Desktop/Debug/
LOG: PrivatePath inicial = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = WpfApp1.exe
Chamando assembly: DevExpress.Xpf.Core.v17.1, Version=17.1.6.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a.
===
LOG: iniciar validação de todas as dependências.
LOG: [Nível 1]iniciar validação de dependência da imagem nativa mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Nível 1]iniciar validação de dependência de IL System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Nível 1]iniciar validação de dependência de IL System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Nível 1]iniciar validação de dependência da imagem nativa System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Nível 1]iniciar validação de dependência da imagem nativa System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Nível 2]iniciar validação de dependência da imagem nativa mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Nível 2]iniciar validação de dependência da imagem nativa System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Nível 2]iniciar validação de dependência de IL System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
Native image has correct version information.
LOG: [Nível 1]iniciar validação de dependência de IL Accessibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Nível 1]iniciar validação de dependência de IL System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Nível 1]iniciar validação de dependência de IL System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: [Nível 1]iniciar validação de dependência de IL System.Deployment, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: [Nível 1]iniciar validação de dependência de IL System.Runtime.Serialization.Formatters.Soap, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
Native image has correct version information.
LOG: a validação das dependências foi bem-sucedida.
LOG: a associação com a imagem nativa foi bem-sucedida.
Attempting to use native image C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Windows.Forms\46cc21f2e6e3d23302f401cb2a4f55ad\System.Windows.Forms.ni.dll.
Rejecting native image because dependency C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll is not native
não entendi muito bem a causa dos erros, parece algo na System.dll
se poder me dar uma orientação fico muito grato, estou algumas semanas tentando finalizar o instalador qualquer ajuda seria bem vinda.
Olá Walmir!
Pelo que percebi na mensagem de erro, você está utilizando os controles da DevExpress nesse seu projeto.. Você não esqueceu de incluir as dlls da DevExpress na pasta da aplicação (DevExpress.Xpf.Core.dll e dlls relacionadas)?
Abraço!
André Lima