Pergunta

Meu .NET importações de aplicação 2.0 não gerenciado de 32 bits dll. A DLL é carregada (primeira chamada interoperabilidade acontece) quando o usuário abre um arquivo através de um diálogo dentro do aplicativo.

Quando eu implantar o aplicativo via clickonce com plataforma de destino "Qualquer", os usuários em 64 bits do Windows obter BadImageFormatException ao tentar abrir arquivos do aplicativo (no momento a dll não gerenciada é carregado). Eu entendo que isso é devido a bitness incompabible do processo de 64 bits e de 32 bits dll não gerenciada.

Eu reimplantado o aplicativo usando x86 como plataforma de destino. Pelo que entendi, isso deve resolver o problema bitness.

MAS

Quando eu executar o implantado aplicação construído para x86 no sistema de 64 bits, eu agora obter BadImageFormatException imediatamente antes da aplicação começa mesmo. Testado em pelo menos três máquinas de 64 bits. Em máquinas de 32 bits, ele funciona sem nenhum problema.

Quando eu executar o aplicativo diretamente a partir de VS (ou não diretamente, apenas uma compilação normal, não vai via ClickOnce), não há nenhum problema em 64 bits do Windows ao usar plataforma de destino x86. O aplicativo é iniciado e usuário pode carregar o arquivo -. A chamada interoperabilidade sucede

Eu tenho depuração isso por 2 dias seguidos sem resultado - Eu tentei em computadores diferentes. Parece que funciona consistentnly em um dos computadores que eu tentei. No entanto, eu não tenho acesso permanente a este computador.

Eu conseguiram construir a implantação ClickOnce no meu computador uma vez e funcionou em uma máquina de 64 bits. Este foi única de talvez 100 tentativas! Nada mudou, a variável só mudou foi que eu fiz a compilação bem-sucedida imediatamente após o reinício do computador.

eu fiz limpo / reconstruir / reiniciar VS / o Windows reiniciar muitas vezes. Tenho reinstalado VS 2008 e agora também toda OS, isso não ajuda.


EDIT: Eu tenho apenas conseguiu obter uma boa construção (fora do próximo 100 :)) e fez comparação entre os diretórios implantados. A origem do problema é que ClickOnce gera a plataforma alvo errado no manifesto do .exe principal:

<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />

processorArchitecture deve ser x86.

Então a questão é como forçar consistentemente VS para gerar o processorArchitecture correta no manifesto ao implantar.

alguém pode ajudar por favor?

Foi útil?

Solução

Isto foi resolvido através da instalação de VS 2008 SP1 em 64 bits do Windows 7. VS2008 SP1 no XP teve o problema em duas máquinas Eu tentei com.

Outras dicas

Eu tive esse problema também, usando VS2008 SP1. No meu caso, tinha um DLL de 32 bits, que teve de ser compilado como de 32 bits e uma aplicação que foi utilizando-o na mesma solução. Mesmo que eu especificado X86 como o destino de compilação para a compilação de lançamento, quando eu publiquei um aplicativo de 64 bits foi compilado e incluído no instalador. Eu encontrei uma solução um pouco brutal para o problema: Vá para o gerenciador de configuração e remover todas as configurações possíveis, exceto o que você quer que ele construção (Debug e versões de lançamento). Depois de fazer isso, descobri que o instalador clickonce foi gerado com a aplicação correta.

Espero que isso ajude alguém, eu tenho lutado contra este problema e fora por meses.

Eu sugiro usar refletor para abrir o principal exe implantado pelo ClickOnce e ver a dependências para certificar-se você não estiver implantando a versão da dll de 64 bits por engano.

Você deve resolver para executar aplicativos de 32 bits no IIS 7. Consulte http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Às vezes o processo de publicação ClickOnce parece para armazenar em cache os arquivos antigos anteriores Qualquer CPU ou x64 constrói. Fazendo uma limpa e reconstruir tudo não corrigir esse problema para mim. Eu precisava eliminar todo o bin e obj pastas de meus projetos e reabrir Visual Studio.

Nós correu para este problema e determinou que o subdiretório do perfil de usuário para que ClickOnce implantado o nosso pedido deve ter sido corrompido, porque fomos capazes de implementar a aplicação com sucesso com ClickOnce quando logado como um usuário diferente na mesma máquina .

Nós fomos capazes de resolver o problema simplesmente apagando o subdiretório de C:\Users\<user>\AppData\Local\Apps em que ClickOnce foi implantando nossa aplicação. No nosso caso, este foi C:\Users\<user>\AppData\Local\Apps\2.0.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top