PROBLEMA DE IMPLANTA?ÃO CLIENTE
Boa noite!
Terminei meu aplicativo C# criado no VS 2008 Pro, usando framework 3.5 com SQL Server 2008 Express e desenvolvido em micro com windows 7 32 bits.
Tudo funcionando perfeitamente no meu micro. Fiz um teste acessando um outro micro através de um roteador (simulando uma rede), onde o roteador e os 2 micros possuem firewall. No meu micro executei meu programa para conectar ao SQL do outro micro usando tanto o nome do host como seu IP definido para ele pelo roteador, tudo funcionou PERFEITAMENTE.
Fui implantar no primeiro cliente e aparecerem alguns problemas.
O primeiro o TI criou uma máquina virtual e meu programa não conseguia se conectar ao SQL usando nome de host, somente via IP. Até aà sem ao menos conectou. e pude criar os bancos.
Porém na hora de entrar com usuário e senha ele começou a dar erro de campo inexistente no banco. Verificamos manualmente e tudo está certo no SQL. Então o TI usou um recurso do Windows para rastrear o que estava sendo feito e ele acusa que meu programa ao rodar estava usando o dot.net .2.0 e não o 3.5 que foi criado. Sendo que ele está corretamente instalado no micro. Tentamos instalar o Dot.net 3.5 manualmente, mas o Windows não deixa e fala que tem de instalar a versão 4.61 (últmia), mas isso não tem lógica, pois o 3.5 não tem nenhuma relação com as versões posteriores, apenas com as anteriores.
Fiz alterações no código pois detectei um problema, onde um dos projetos de um componente usava a versão 2.0, não entendi, pois todos os projetos principais estavam para 3.5. Mudei esse controle e duto ficou correto. Os projetos estão configurador para Any CPU em todos, assim penso que irão rodar tanto no 32 como 64 bits.
Mas ao rodar agora meu programa ele é travado pelo windows com o seguinte erro:
Descrição:
Stopped working
Assinatura do problema:
Nome do Evento de Problema: CLR20r3
Assinatura do Problema 01: meuPrograma.exe
Assinatura do Problema 02: 7.0.0.1
Assinatura do Problema 03: 57755344
Assinatura do Problema 04: meuPrograma
Assinatura do Problema 05: 7.0.0.1
Assinatura do Problema 06: 57755344
Assinatura do Problema 07: 1b14
Assinatura do Problema 08: 31
Assinatura do Problema 09: System.BadImageFormatException
Versão do sistema operacional: 6.1.7601.2.1.0.256.48
Identificação da Localidade: 1046
Pelo que sei esse erro é uma incompatibilidade do CLR20r3 com o programa criado em Dot.net ( no caso o meu ). Tive esse mesmo problema com o Crystal Report. Após baixar o instalador de distribuição dos componentes dele, isso foi resolvido num micro que testei aqui.
Porém no cliente acho que tem relação com a versão 64 bits do windows.
Minha pergunta tem duas partes:
1) Estou usando algumas bibliotecas do Visual Studio que é 32 bits. Será que pode ser isso? Elas são distribuÃdas junto com meu programa, mas não vejo lógica se for isso.
os arquivos são:
Microsoft.VisualBasic.PowerPacks.Vs.dll
Microsoft.VisualBasic.dll
Alguém tem alguma ideia, já passou por algo parecido?
2) Tinha incluÃdo um manifest no programa, e agora tirei para ver se resolvia, mas nada. Esse manifest é realmente necessário? Como saber exatamente o que incluir nele?
Terminei meu aplicativo C# criado no VS 2008 Pro, usando framework 3.5 com SQL Server 2008 Express e desenvolvido em micro com windows 7 32 bits.
Tudo funcionando perfeitamente no meu micro. Fiz um teste acessando um outro micro através de um roteador (simulando uma rede), onde o roteador e os 2 micros possuem firewall. No meu micro executei meu programa para conectar ao SQL do outro micro usando tanto o nome do host como seu IP definido para ele pelo roteador, tudo funcionou PERFEITAMENTE.
Fui implantar no primeiro cliente e aparecerem alguns problemas.
O primeiro o TI criou uma máquina virtual e meu programa não conseguia se conectar ao SQL usando nome de host, somente via IP. Até aà sem ao menos conectou. e pude criar os bancos.
Porém na hora de entrar com usuário e senha ele começou a dar erro de campo inexistente no banco. Verificamos manualmente e tudo está certo no SQL. Então o TI usou um recurso do Windows para rastrear o que estava sendo feito e ele acusa que meu programa ao rodar estava usando o dot.net .2.0 e não o 3.5 que foi criado. Sendo que ele está corretamente instalado no micro. Tentamos instalar o Dot.net 3.5 manualmente, mas o Windows não deixa e fala que tem de instalar a versão 4.61 (últmia), mas isso não tem lógica, pois o 3.5 não tem nenhuma relação com as versões posteriores, apenas com as anteriores.
Fiz alterações no código pois detectei um problema, onde um dos projetos de um componente usava a versão 2.0, não entendi, pois todos os projetos principais estavam para 3.5. Mudei esse controle e duto ficou correto. Os projetos estão configurador para Any CPU em todos, assim penso que irão rodar tanto no 32 como 64 bits.
Mas ao rodar agora meu programa ele é travado pelo windows com o seguinte erro:
Descrição:
Stopped working
Assinatura do problema:
Nome do Evento de Problema: CLR20r3
Assinatura do Problema 01: meuPrograma.exe
Assinatura do Problema 02: 7.0.0.1
Assinatura do Problema 03: 57755344
Assinatura do Problema 04: meuPrograma
Assinatura do Problema 05: 7.0.0.1
Assinatura do Problema 06: 57755344
Assinatura do Problema 07: 1b14
Assinatura do Problema 08: 31
Assinatura do Problema 09: System.BadImageFormatException
Versão do sistema operacional: 6.1.7601.2.1.0.256.48
Identificação da Localidade: 1046
Pelo que sei esse erro é uma incompatibilidade do CLR20r3 com o programa criado em Dot.net ( no caso o meu ). Tive esse mesmo problema com o Crystal Report. Após baixar o instalador de distribuição dos componentes dele, isso foi resolvido num micro que testei aqui.
Porém no cliente acho que tem relação com a versão 64 bits do windows.
Minha pergunta tem duas partes:
1) Estou usando algumas bibliotecas do Visual Studio que é 32 bits. Será que pode ser isso? Elas são distribuÃdas junto com meu programa, mas não vejo lógica se for isso.
os arquivos são:
Microsoft.VisualBasic.PowerPacks.Vs.dll
Microsoft.VisualBasic.dll
Alguém tem alguma ideia, já passou por algo parecido?
2) Tinha incluÃdo um manifest no programa, e agora tirei para ver se resolvia, mas nada. Esse manifest é realmente necessário? Como saber exatamente o que incluir nele?
Talvez isso esteja acontecendo por uma questão de segurança do sistema operacional. Faça o seguinte teste:
Clique com o botão direito em [Ô]Computador[Ô] e depois em [Ô]Propriedades[Ô].
Escolha [Ô]Configurações Avançadas do Sistema[Ô] e na aba [Ô]Avançado[Ô] clique em [Ô]Configurações[Ô]. Localize a parte referente a DEP (Prevenção de Execução de Dados), clique nela e na opção [Ô]Ativar a DEP para todos os programas e serviços, exceto os que eu selecionar[Ô].
Abaixo clique em adicionar, adicione o executável do programa que está dando erro, reinicie o PC e veja se o problema sumiu.
Clique com o botão direito em [Ô]Computador[Ô] e depois em [Ô]Propriedades[Ô].
Escolha [Ô]Configurações Avançadas do Sistema[Ô] e na aba [Ô]Avançado[Ô] clique em [Ô]Configurações[Ô]. Localize a parte referente a DEP (Prevenção de Execução de Dados), clique nela e na opção [Ô]Ativar a DEP para todos os programas e serviços, exceto os que eu selecionar[Ô].
Abaixo clique em adicionar, adicione o executável do programa que está dando erro, reinicie o PC e veja se o problema sumiu.
O mais comum neste tipo de erro é você estar usando algum componente 32 bits em seu programa, geralmente algo não gerenciado como alguma biblioteca COM.
Como você está compilando para Any CPU o seu programa vai rodar como um processo de 64 bits em sistemas operacionais de 64 bits, e um programa que esteja rodando como 64 bits não pode de forma alguma usar componentes de 32 bits.
O que se faz nestes casos é forçar o programa a rodar sempre como 32 bits, mudando de Any CPU para x86, assim independente do sistema operacional ele sempre vai executar como 32 bits, lembrando que o Windows de 64 bits consegue executar programas de 32 bits.
Como você está compilando para Any CPU o seu programa vai rodar como um processo de 64 bits em sistemas operacionais de 64 bits, e um programa que esteja rodando como 64 bits não pode de forma alguma usar componentes de 32 bits.
O que se faz nestes casos é forçar o programa a rodar sempre como 32 bits, mudando de Any CPU para x86, assim independente do sistema operacional ele sempre vai executar como 32 bits, lembrando que o Windows de 64 bits consegue executar programas de 32 bits.
Bom dia amigos.
O estranho é que ele inicia, abre a tela de conexão com o SQL Server, finaliza e depois na hora de fazer login para entrar no sistema ele trava com esse erro de CLR. Isso passou a ocorrer depois que recompilei para rodar como Any CPU em tudo, antes ele dava um erro de que não havia um campo no banco, mas estava tudo certo.
JABA quer dizer que mesmo um programa feito em Dot.net precisa autorizar no DEP também? Mas se fosse isso, como ele abria o programa, faria uma série de rotinas, até o teste com o SQL Server e travaria só em outra tela de login?
OCELOT Que eu saiba não estou usando nenhum componente COM. A princÃpio todas as DLLs são Dot.Net, tem as que eu fiz no próprio projeto e algumas que peguei descritas abaixo: Porém não tenho como saber se elas forma feitas também Any CPU ou X86.
Copiadas do próprio VS 2008 - aqui eu tenho dúvida, pois como meu VS é 32 bits, será que suas DLLs estão Any CPU também ou a insalação do VS analisa e instala conforme a plataforma do Windows?
Microsoft.VisualBasic.PowerPacks.Vs.dll
Microsoft.VisualBasic.dll
Bibliotecas de Terceiros - São funcionalidades de Compactação, acesso a WebCan e PDF
ICSharpCode.SharpZipLib.dll
Interop.AcroPDFLib.dll
AxInterop.AcroPDFLib.dll
AForge.Video.dll
AForge.Video.DirectShow.dll
Nota: Se eu compilar meu programa todo (EXE e DLLs) para rodar na plataforma 32 bits, e instalar em modo compatibilidade 32 bits ele vai funcionar em qualquer 64 bits?
O estranho é que ele inicia, abre a tela de conexão com o SQL Server, finaliza e depois na hora de fazer login para entrar no sistema ele trava com esse erro de CLR. Isso passou a ocorrer depois que recompilei para rodar como Any CPU em tudo, antes ele dava um erro de que não havia um campo no banco, mas estava tudo certo.
JABA quer dizer que mesmo um programa feito em Dot.net precisa autorizar no DEP também? Mas se fosse isso, como ele abria o programa, faria uma série de rotinas, até o teste com o SQL Server e travaria só em outra tela de login?
OCELOT Que eu saiba não estou usando nenhum componente COM. A princÃpio todas as DLLs são Dot.Net, tem as que eu fiz no próprio projeto e algumas que peguei descritas abaixo: Porém não tenho como saber se elas forma feitas também Any CPU ou X86.
Copiadas do próprio VS 2008 - aqui eu tenho dúvida, pois como meu VS é 32 bits, será que suas DLLs estão Any CPU também ou a insalação do VS analisa e instala conforme a plataforma do Windows?
Microsoft.VisualBasic.PowerPacks.Vs.dll
Microsoft.VisualBasic.dll
Bibliotecas de Terceiros - São funcionalidades de Compactação, acesso a WebCan e PDF
ICSharpCode.SharpZipLib.dll
Interop.AcroPDFLib.dll
AxInterop.AcroPDFLib.dll
AForge.Video.dll
AForge.Video.DirectShow.dll
Nota: Se eu compilar meu programa todo (EXE e DLLs) para rodar na plataforma 32 bits, e instalar em modo compatibilidade 32 bits ele vai funcionar em qualquer 64 bits?
Citação:JABA quer dizer que mesmo um programa feito em Dot.net precisa autorizar no DEP também?
Se eu mandei você fazer um teste, não entendi o motivo de sua pergunta.
Citação:Nota: Se eu compilar meu programa todo (EXE e DLLs) para rodar na plataforma 32 bits, e instalar em modo compatibilidade 32 bits ele vai funcionar em qualquer 64 bits?
Sim, ele rodará perfeitamente mesmo em plataforma 64 bits.
Ok vou fazer os testes.
Obrigado e retorno com o resultado.
Obrigado e retorno com o resultado.
Só de ver a sua lista de DLLs as seguintes já me levantam a suspeita
Interop.AcroPDFLib.dll
AxInterop.AcroPDFLib.dll
AForge.Video.dll
AForge.Video.DirectShow.dll
No geral DLLs Interop* ou AxInterop* são DLLs de interoperabilidade com COM, e estas duas primeiras são o mais provável de causar o problema, já que estas duas são na verdade o que permite você usar o AcroPDFLib.dll que é uma biblioteca nativa, e muito provavelmente só exista uma versão de 32 bits.
Já o AForge eu não sei dizer, mas como é uma biblioteca que usa componentes nativos sempre existe a chance de não funcionar ou as vezes de ter versões especificas para 64 ou 32 bits.
Mas podemos concluir que simplesmente pelo uso do AcroPDFLib você já vai ser obrigado a compilar seu programa como 32 bits para funcionar, e não precisa fazer mais nada além de mudar o seu EXE para ser 32 bits, as DLLs não existe necessidade de mudar se estiverem como Any CPU, quem manda ai é o EXE mesmo, o Windows de 64 vai conseguir rodar ele sem problemas e sem precisar mudar nenhuma configuração, não existe necessidade de modo de compatibilidade.
A limitação que existe no Windows de 64 bits é que um programa de 64 bits só pode usar componentes de 64 bits e um de 32 bits só pode usar componentes de 32 bits, que é exatamente o motivo do seu erro, o seu programa que estava rodando como 64 bits tentou carregar o AcroPDFLib.dll que é de 32 bits.
Interop.AcroPDFLib.dll
AxInterop.AcroPDFLib.dll
AForge.Video.dll
AForge.Video.DirectShow.dll
No geral DLLs Interop* ou AxInterop* são DLLs de interoperabilidade com COM, e estas duas primeiras são o mais provável de causar o problema, já que estas duas são na verdade o que permite você usar o AcroPDFLib.dll que é uma biblioteca nativa, e muito provavelmente só exista uma versão de 32 bits.
Já o AForge eu não sei dizer, mas como é uma biblioteca que usa componentes nativos sempre existe a chance de não funcionar ou as vezes de ter versões especificas para 64 ou 32 bits.
Mas podemos concluir que simplesmente pelo uso do AcroPDFLib você já vai ser obrigado a compilar seu programa como 32 bits para funcionar, e não precisa fazer mais nada além de mudar o seu EXE para ser 32 bits, as DLLs não existe necessidade de mudar se estiverem como Any CPU, quem manda ai é o EXE mesmo, o Windows de 64 vai conseguir rodar ele sem problemas e sem precisar mudar nenhuma configuração, não existe necessidade de modo de compatibilidade.
A limitação que existe no Windows de 64 bits é que um programa de 64 bits só pode usar componentes de 64 bits e um de 32 bits só pode usar componentes de 32 bits, que é exatamente o motivo do seu erro, o seu programa que estava rodando como 64 bits tentou carregar o AcroPDFLib.dll que é de 32 bits.
Entendi OCELOT, então vou recompilar o EXE para 32 bits.
porém tenho mais uma dúvida. Eu envio no Inno Setup o instalador MSI do Crystal Reporte. Tanto versão 32 como 64 bits, onde o Inno verifica o sistema e instala.
No momento da instalação, emitiu um aviso de erro que não podia instalar o pacote msi, e em seguida executou o instalador do Crystal. Não sei exatamente o que ocorreu, se um erro no Inno tentando instalar ambos os MSI (32 e 64).
Isso gerou a dúvida: Ao distribuir meu sistema agora para 32 bits, tenho de instalar apenas o Crystal como 32 bits e retirar a versão 64 bits?
Uma das DLLs que citei acima descobri que foi criada com framework 2.0, sendo que o meu programa foi em 3.5. Isso não deve gerar problema certo?
porém tenho mais uma dúvida. Eu envio no Inno Setup o instalador MSI do Crystal Reporte. Tanto versão 32 como 64 bits, onde o Inno verifica o sistema e instala.
No momento da instalação, emitiu um aviso de erro que não podia instalar o pacote msi, e em seguida executou o instalador do Crystal. Não sei exatamente o que ocorreu, se um erro no Inno tentando instalar ambos os MSI (32 e 64).
Isso gerou a dúvida: Ao distribuir meu sistema agora para 32 bits, tenho de instalar apenas o Crystal como 32 bits e retirar a versão 64 bits?
Uma das DLLs que citei acima descobri que foi criada com framework 2.0, sendo que o meu programa foi em 3.5. Isso não deve gerar problema certo?
Eu não uso Crystal então não tenho como dizer com certeza o que ele instala, mas eu diria para testar instalar apenas a versão de 32 bits mesmo independente do sistema operacional.
Quanto a DLL ser do .Net 2.0 não deve ter problema, já que o .Net 2.0, 3.0 e o 3.5 usam a mesma versão do CLR, o .Net 3.5 é praticamente um extensão do .Net 2.0
E como o seu programa vai ser sempre de 32 bits na instalação você deve sempre procurar usar os pacotes de 32 bits, pode existir alguma exceção, eu não descartaria a chance de existir um pacote especifico para Windows de 64 bits que instala neste Windows os componentes tanto de 32 quanto de 64 bits, mas é mais comum ver isso no caso de precisar de drivers, de cabeça me lembro de um instalador que fiz que instalava um driver USB que possuÃa duas versões, e na versão de 64 bits ele instalava o driver de 64 bits e o componente de 32 bits, então neste caso mesmo o programa sendo de 32 bits precisava instalar a versão correta para a arquitetura do Windows.
Quanto a DLL ser do .Net 2.0 não deve ter problema, já que o .Net 2.0, 3.0 e o 3.5 usam a mesma versão do CLR, o .Net 3.5 é praticamente um extensão do .Net 2.0
E como o seu programa vai ser sempre de 32 bits na instalação você deve sempre procurar usar os pacotes de 32 bits, pode existir alguma exceção, eu não descartaria a chance de existir um pacote especifico para Windows de 64 bits que instala neste Windows os componentes tanto de 32 quanto de 64 bits, mas é mais comum ver isso no caso de precisar de drivers, de cabeça me lembro de um instalador que fiz que instalava um driver USB que possuÃa duas versões, e na versão de 64 bits ele instalava o driver de 64 bits e o componente de 32 bits, então neste caso mesmo o programa sendo de 32 bits precisava instalar a versão correta para a arquitetura do Windows.
Eu compilo sempre em 32 bits e uso no cliente Crystal 32 bits, assim evito alguns problemas de compatibilidade
Aqui uso Win10 64 bits.
Aqui uso Win10 64 bits.
no script do innosetup vc instala a versão de acordo c o SO, já vi isso, nunca usei, precisa uma boa busca
Faça seu login para responder