Domanda

La mia applicazione .NET 2.0 importa dll a 32 bit non gestita. La dll viene caricata (si verifica la prima chiamata di interoperabilità) quando l'utente apre un file tramite una finestra di dialogo all'interno dell'applicazione.

Quando distribuisco l'applicazione tramite clickonce con la piattaforma di destinazione " Qualsiasi " ;, gli utenti su finestre a 64 bit ottengono BadImageFormatException quando provano ad aprire file dall'applicazione (al momento viene caricata la dll non gestita) . Capisco che ciò è dovuto all'incomprimibile testimone del processo a 64 bit e alla dll non gestita a 32 bit.

Ho ridistribuito l'applicazione usando x86 come piattaforma di destinazione. A quanto ho capito, questo dovrebbe risolvere il problema del testimone.

MA

Quando eseguo l'applicazione distribuita creata per x86 su un sistema a 64 bit, ora ottengo BadImageFormatException immediatamente prima ancora che l'applicazione venga avviata. Testato su almeno tre macchine a 64 bit. Su macchine a 32 bit, funziona senza problemi.

Quando eseguo l'applicazione direttamente da VS (o non direttamente, solo una build normale, non passando tramite ClickOnce), non si verificano problemi su Windows a 64 bit quando si utilizza la piattaforma di destinazione x86. L'applicazione si avvia e l'utente può caricare il file - la chiamata di interoperabilità ha esito positivo.

Ho eseguito il debug per 2 giorni consecutivi senza risultati - ho provato su diversi computer. Sembra funzionare coerentemente su uno dei computer che ho provato. Tuttavia, non ho accesso permanente a questo computer.

Sono riuscito a creare una volta la distribuzione ClickOnce sul mio computer e ha funzionato su una macchina a 64 bit. Questo è stato singolo di forse 100 tentativi! Non è cambiato nulla, l'unica variabile modificata è che ho eseguito correttamente la build subito dopo il riavvio del computer.

Ho pulito / ricostruito / riavviato VS / riavviato MOLTE volte. Ho reinstallato VS 2008 e ora anche l'intero sistema operativo, non ha aiutato.


EDIT: sono appena riuscito a ottenere una buona build (tra i prossimi 100 :)) e ho fatto un confronto tra le directory distribuite. La fonte del problema è che ClickOnce genera la piattaforma di destinazione errata nel manifest del file .exe principale:

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

processorArchitecture dovrebbe essere x86.

Quindi la domanda è come forzare costantemente VS a generare l'architettura di processore corretta nel manifest durante la distribuzione.

Qualcuno può aiutare per favore?

È stato utile?

Soluzione

Ciò è stato risolto installando VS 2008 SP1 su Windows a 64 bit 7. VS2008 SP1 su XP ha avuto il problema su due macchine con cui ho provato.

Altri suggerimenti

Ho avuto anche questo problema, usando VS2008 SP1. Nel mio caso avevo una DLL a 32 bit che doveva essere compilata come 32 bit e un'applicazione che la utilizzava nella stessa soluzione. Anche se ho specificato X86 come target di build per la build di rilascio, quando ho pubblicato un'applicazione a 64 bit è stata compilata e inclusa nel programma di installazione. Ho trovato una soluzione leggermente brutale al problema: Accedi al gestore della configurazione e rimuovi tutte le possibili configurazioni tranne quella che desideri creare (versioni di debug e di rilascio). Dopo aver fatto questo ho scoperto che il programma di installazione clickonce è stato generato con l'applicazione corretta.

Spero che questo aiuti qualcun altro, ho combattuto questo problema dentro e fuori per mesi.

Suggerirei di usare Reflector per aprire l'esempio principale distribuito da ClickOnce e vedere il dipendenze per assicurarsi che non si stia distribuendo la versione a 64 bit della dll per errore.

È necessario risolvere per eseguire le applicazioni a 32 bit in IIS 7. Vedere http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

A volte il processo di pubblicazione ClickOnce sembra memorizzare nella cache i vecchi file delle precedenti versioni di Any CPU o x64. Fare una pulizia e ricostruire tutto non ha risolto questo problema per me. Avevo bisogno di eliminare tutte le cartelle bin e obj dai miei progetti e riaprire Visual Studio.

Abbiamo riscontrato questo problema e abbiamo stabilito che la sottodirectory del profilo utente in cui ClickOnce ha distribuito la nostra applicazione deve essere corrotta, perché siamo riusciti a distribuire correttamente l'applicazione con ClickOnce quando abbiamo effettuato l'accesso come un altro utente sullo stesso computer .

Siamo stati in grado di risolvere il problema semplicemente eliminando la sottodirectory di C:\Users\<user>\AppData\Local\Apps in cui ClickOnce stava distribuendo la nostra applicazione. Nel nostro caso, questo era C:\Users\<user>\AppData\Local\Apps\2.0.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top