"È stato effettuato un tentativo di caricare un programma con un formato errato" anche quando le piattaforme sono uguali

Sto chiamando funzioni da una DLL non gestita a 32 bit su un sistema a 64 bit. Quello che ottengo è:

BadImageFormatException: è stato effettuato un tentativo di caricare un programma con un formato errato. (Eccezione da HRESULT: 0x8007000B)

Inizialmente, i miei progetti erano impostati sulla piattaforma Any CPU, quindi li ho cambiati entrambi in x86, ma l'errore si sta ancora verificando. Questa è davvero l'unica soluzione che conosco per questo.

Le DLL non sono corrotte o altro, perché posso usarle con altri programmi (di cui non ho la fonte). Ho pensato che forse non stava trovando una dipendenza, ma ho controllato e sono tutti lì. Inoltre, DllNotFoundExceptionin questo caso non lo lancerebbe ?

Cos'altro posso fare? E prima di dire "Usa invece una DLL non gestita a 64 bit", lasciami sottolineare che non ce n'è una. ;)

Se si tenta di eseguire applicazioni a 32 bit su IIS 7 (e / o computer con sistema operativo a 64 bit), si otterrà lo stesso errore. Quindi, da IIS 7, fai clic con il pulsante destro del mouse sul pool di applicazioni delle applicazioni e vai su "Impostazioni avanzate" e modifica "Abilita applicazioni a 32 bit" su "VERO".

Riavvia il tuo sito Web e dovrebbe funzionare.

In qualche modo, il casella di controllo Build in Configuration Manager era deselezionata per il mio eseguibile, quindi era ancora in esecuzione con la vecchia build Any CPU. Dopo averlo risolto, Visual Studio si è lamentato del fatto che non è stato possibile eseguire il debug dell'assembly, ma che è stato risolto con un riavvio.

In Visual Studio , fai clic con il pulsante destro del mouse sul progetto -> Nel riquadro sinistro fai clic sulla scheda Genera ,

in Target piattaforma selezionare x86 (o più in generale l' architettura da abbinare alla libreria a cui ci si collega)

Spero che questo aiuti qualcuno! :)

Ho avuto anche questo problema. Ho provato tutti i suggerimenti qui, ma non hanno aiutato.

Ho trovato un'altra cosa da verificare che l'ha risolto per me. In Visual Studio, fai clic con il pulsante destro del mouse sul progetto e apri "Proprietà". Fai clic sulla scheda "Compila" (o "Crea"), quindi fai clic su "Opzioni di compilazione avanzate" nella parte inferiore.

Controllare il menu a discesa "CPU di destinazione". Dovrebbe corrispondere alla "Piattaforma" che stai costruendo. Cioè, se stai costruendo "Any CPU", allora "Target CPU" dovrebbe dire "Any CPU". Esamina tutte le tue piattaforme rendendole attive e controlla questa impostazione.

Se si verifica questo errore quando si fa clic sul pulsante freccia verde per eseguire l'applicazione, ma si desidera comunque eseguire l'app a 64 bit. Puoi farlo in VS 2013, 2015, 2017 e 2019

Vai a: Strumenti> Opzioni> Progetti e soluzioni> Progetti Web> Usa la versione a 64 bit di IIS Express

Se si utilizza Any CPU , è possibile che si verifichi questo problema se l' opzione Prefer 32 bit è selezionata:

Assicurati di deselezionare questa opzione nella scheda Costruisci della proprietà del progetto !

Un po 'fuori tema per questo post, ma la ricerca di questo messaggio di errore mi ha portato qui.

Se stai compilando il sistema del team e ricevi questo errore, la scheda del processo di definizione build ha un'impostazione "Piattaforma MSBuild". Se impostato su "Auto", è possibile che si verifichi questo problema. Modificandolo in "X86" è anche possibile risolvere l'errore.

Nel mio caso stavo usando una DLL nativa in C #. Questa DLL dipendeva da un paio di altre DLL mancanti. Una volta aggiunte quelle altre DLL, tutto ha funzionato.

Basandosi sulla risposta di @paibamboo

Ha detto: Vai su: Strumenti> Opzioni> Progetti e soluzioni> Progetti Web> Usa la versione a 64 bit di IIS Express

Il mio collega aveva selezionato questa casella (la cercava esplicitamente), ma aveva il messaggio di errore in questione. Dopo alcune ore deselezionò la casella e la ricontrollò. Ecco ed ecco: il codice ora funzionava con successo.

Sembra che ci siano due posti in cui viene salvato lo stato di questo riquadro che è diventato non sincronizzato. Deselezionandolo e ricontrollandolo è stato nuovamente sincronizzato.

Domanda per utenti più competenti: c'è stato un aggiornamento o qualcosa della scorsa settimana (per VS 2015) che ha sincronizzato gli stati?

Vedi anche questa risposta , che ha risolto lo stesso problema per me.

Postato da Luis Mack il 5/12/2010 alle 8:50 Ho riscontrato lo stesso problema, solo per un progetto specifico durante la compilazione su una macchina a 64 bit. Una correzione per far funzionare SEEMS consiste nel modificare manualmente un carattere nel flusso di immagini OGNI VOLTA il controllo utente o il modulo vengono modificati nel designer

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Cambia in

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w

Questo è 00LjAuMC4w di nuovo a 0yLjAuMC4w alla fine della riga (da 00 a 0y)

Nel mio caso, sto usando un piccolo .exe che ricarica le DLL di riferimento tramite Reflection. Quindi faccio solo questi passaggi che mi salvano la giornata:

Dalle proprietà del progetto in Esplora soluzioni, nella scheda build, scelgo target platfrom x86

Nel mio caso, stavo eseguendo dei test tramite MSTest e ho scoperto che stavo distribuendo una directory DLL a 32 e 64 bit nella directory di test. Il programma favoriva la DLL a 64 bit e la faceva fallire.

TL; DR Assicurarsi di distribuire solo DLL a 32 bit nei test.

Abbiamo riscontrato un problema simile e siamo riusciti a risolverlo impostando Target piattaforma su x86.

Ho risolto questo problema nel modo "Windows". Dopo aver controllato tutte le mie impostazioni, pulito la soluzione e ricostruita, ho semplicemente chiuso la soluzione e riaperta. Quindi ha funzionato, quindi VS probabilmente non si è sbarazzato di alcune cose durante la pulizia. Quando le soluzioni logiche non funzionano, di solito mi rivolgo a soluzioni illogiche (o apparentemente illogiche). Windows non mi delude. :)

Sono stato in grado di risolvere questo problema abbinando la mia versione di build alla versione .NET sul server.

Ho fatto doppio clic su .exe solo per vedere cosa sarebbe successo e mi ha detto di installare 4.5 ....

Quindi ho eseguito il downgrade a 4.0 e ha funzionato!

Quindi assicurati che le tue versioni corrispondano. Funzionava bene sulla mia scatola di sviluppo, ma il server aveva una versione .NET precedente.

Nel mio caso il contenuto del file era errato. La DLL è stata scaricata dal web, ma il contenuto della DLL era una pagina HTML: D Prova a verificare se si tratta di un file binario, se sembra che la DLL sia corretta :)

Stavamo riscontrando lo stesso problema in .NET core. La soluzione era scaricare il runtime .netcore a 32 bit e avere il tuo target di progettox86

Nel tuo csprojfile aggiungi

  <PropertyGroup>
    <PlatformTarget>x86</PlatformTarget>  
  </PropertyGroup>

  <PropertyGroup>
    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>    
  </PropertyGroup>

Questo è stato usato per un computer Windows, dovresti regolare i percorsi e simili per Linux / OSX

Se si importa DLL non gestita, utilizzare

CallingConvention = CallingConvention.Cdecl 

nel metodo di importazione DLL.

1: Vai a: Strumenti> Opzioni> Progetti e soluzioni> Progetti Web> Usa la versione a 64 bit di IIS Express 2: modifica le impostazioni seguenti per il progetto di servizio web.