Ik roep functies aan vanaf een 32-bits onbeheerde DLL op een 64-bits systeem. Wat ik krijg is:
BadImageFormatException: er is geprobeerd een programma met een onjuist formaat te laden. (Uitzondering op HRESULT: 0x8007000B)
In het begin had ik mijn projecten ingesteld op het Any CPU-platform, dus ik heb ze allebei gewijzigd in x86, maar deze fout doet zich nog steeds voor. Dat is echt de enige oplossing die ik hiervoor ken.
De DLL’s zijn niet beschadigd of zo, omdat ik ze met andere programma’s kan gebruiken (waarvan ik de bron niet heb). Ik dacht dat het misschien niet het vinden van een afhankelijkheid was, maar ik heb het gecontroleerd en ze zijn er allemaal. Plus, zou het in dat geval geen DllNotFoundException geven?
Wat kan ik nog meer doen? En voordat u zegt: “Gebruik in plaats daarvan een 64-bits onbeheerde DLL”, wil ik erop wijzen dat die er niet is. 😉
Antwoord 1, autoriteit 100%
Als u 32-bits toepassingen probeert uit te voeren op IIS 7 (en/of 64-bits OS-computer), krijgt u dezelfde foutmelding. Dus, vanuit IIS 7, klik met de rechtermuisknop op de applicatiepool van de applicaties en ga naar “geavanceerde instellingen” en verander “Enable 32-Bit Applications” naar “TRUE”.
Herstart uw website en deze zou moeten werken.
Antwoord 2, autoriteit 25%
Op de een of andere manier was het selectievakje Build in de Configuration Manager uitgeschakeld voor mijn uitvoerbare bestand, dus het draaide nog steeds met de oude Any CPU-build. Nadat ik dat had opgelost, klaagde Visual Studio dat het de assembly niet kon debuggen, maar dat werd opgelost met een herstart.
Antwoord 3, autoriteit 16%
Klik in Visual Studio met de rechtermuisknop op uw project -> Klik in het linkerdeelvenster op het tabblad Build,
selecteer onder Platformdoel x86 (of meer in het algemeen de architectuur die overeenkomt met de bibliotheek waarnaar u linkt)
Ik hoop dat dit iemand helpt! 🙂
Antwoord 4, autoriteit 12%
Als u deze fout tegenkomt wanneer u op de groene pijlknop klikt om de toepassing uit te voeren, maar de app toch in 64 bits wilt uitvoeren. U kunt dit doen in VS 2013, 2015, 2017 en 2019
Ga naar: Extra > Opties > Projecten en oplossingen > Webprojecten > Gebruik de 64-bits versie van IIS Express
Antwoord 5, autoriteit 10%
Ik had dit probleem net ook. Heb alle suggesties hier geprobeerd, maar ze hielpen niet.
Ik heb nog iets gevonden om te controleren dat het voor mij heeft opgelost. Klik in Visual Studio met de rechtermuisknop op het project en open “Eigenschappen”. Klik op het tabblad “Compileren” (of “Build”) en klik vervolgens op “Geavanceerde compileeropties” onderaan.
Controleer de vervolgkeuzelijst “Doel-CPU”. Het moet overeenkomen met het “Platform” dat u aan het bouwen bent. Dat wil zeggen, als u “Elke CPU” bouwt, moet “Target CPU” “Elke CPU” zeggen. Doorloop al uw platforms door ze actief te maken en vink deze instelling aan.
Antwoord 6, autoriteit 7%
Als u Elke CPU gebruikt, kunt u dit probleem tegenkomen als de optie Prefer 32-bit is aangevinkt:
Zorg ervoor dat u deze optie uitschakelt op het tabblad Build van de projectproperty!
Antwoord 7, autoriteit 2%
In mijn geval gebruikte ik een native DLL in C#. Deze DLL was afhankelijk van enkele andere DLL’s die ontbraken. Toen die andere DLL’s eenmaal waren toegevoegd, werkte alles.
Antwoord 8
Een beetje off-topic voor dit bericht, maar zoeken naar deze foutmelding bracht me hier.
Als u via een teamsysteem aan het bouwen bent en deze fout krijgt, heeft het tabblad builddefinitieproces de instelling “MSBuild Platform”. Als dit is ingesteld op “Auto”, kunt u dit probleem ervaren. Door het te wijzigen in “X86” kan de fout ook worden opgelost.
Antwoord 9
We hadden een soortgelijk probleem en we hebben het opgelost door het Platform-doel in te stellen op x86. 
Antwoord 11
Met Visual Studio 2019 had ik een soortgelijk probleem toen ik tests wilde uitvoeren (MSTest rechtstreeks vanuit VS). In mijn geval had ik alleen een x64 native DLL en kreeg ik deze foutmelding. Eerst dacht ik dat het kwam omdat Visual Studio als x86 draait, maar deze pagina heeft me geholpen het probleem op te lossen:
Eenheidstest uitvoeren als een 64-bits proces
Er staat
- Stel uw projecten in op Elke CPU
- Definieer de processorarchitectuur expliciet
Ik heb beide gedaan (ik heb x64 expliciet ingesteld) en toen begonnen mijn tests te werken.
Antwoord 12
Voortbouwend op het antwoord van @paibamboo
Hij zei: Ga naar: Tools > Opties > Projecten en oplossingen > Webprojecten > Gebruik de 64-bits versie van IIS Express
Mijn collega had dit vakje aangevinkt (hij zocht er expliciet naar), maar had de betreffende foutmelding. Na een paar uur haalde hij het vinkje uit het vakje en controleerde het opnieuw. Kijk eens aan: de code is nu met succes uitgevoerd.
Het lijkt erop dat er twee plaatsen zijn waar de status van deze box is opgeslagen, die niet meer synchroon liep. Door het te de- en opnieuw te controleren, werd het opnieuw gesynchroniseerd.
Vraag voor gebruikers met meer kennis: was er vorige week een update of iets dergelijks (voor VS 2015) waardoor de toestanden werden gedesynchroniseerd?
Antwoord 13
Zie ook dit antwoord, dat hetzelfde probleem voor mij oploste.
Geplaatst door Luis Mack op 12-5-2010 om 8:50 uur Ik heb hetzelfde probleem gevonden, alleen voor een specifiek project bij het compileren op een 64-bits machine. Een oplossing die LIJKT te werken, is om handmatig één teken in de afbeeldingsstroom te wijzigen ELKE KEER dat de gebruikersbesturing of het formulier wordt bewerkt in de ontwerper
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4wWijzigen in
AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4wDat is 00LjAuMC4w terug naar 0yLjAuMC4w aan het einde van de regel (00 terug naar 0y)
Antwoord 14
In mijn geval gebruik ik een kleine .exe die de DLL’s waarnaar wordt verwezen via Reflection opnieuw laadt. Dus ik doe gewoon deze stappen die mijn dag redden:
Van de projecteigenschappen in de oplossingsverkenner, op het tabblad Bouwen, kies ik doelplatfrom x86
Antwoord 15
In mijn geval voerde ik tests uit via MSTest en ontdekte dat ik zowel een 32-bits als een 64-bits DLL in de testdirectory implementeerde. Het programma gaf de voorkeur aan de 64-bits DLL en zorgde ervoor dat het faalde.
TL;DR Zorg ervoor dat u alleen 32-bits DLL’s voor tests implementeert.
Antwoord 16
In mijn geval was het de verkeerde inhoud van het bestand. DLL is gedownload van internet, maar de inhoud van de DLL was HTML-pagina 😀
Probeer te controleren of het een binair bestand is, als het lijkt alsof het een correcte DLL is 🙂
Antwoord 17
Ik heb dit probleem op de ‘Windows’-manier opgelost. Nadat ik al mijn instellingen heb gecontroleerd, de oplossing heb schoongemaakt en opnieuw heb opgebouwd, sluit ik de oplossing en heropende ik deze. Toen werkte het, dus VS heeft waarschijnlijk wat spullen niet weggegooid tijdens het schoonmaken.
Als logische oplossingen niet werken, ga ik meestal naar onlogische (of schijnbaar onlogische) oplossingen. Windows laat me niet in de steek. 🙂
Antwoord 18
Ik heb dit probleem kunnen oplossen door mijn buildversie af te stemmen op de .NET-versie op de server.
Ik dubbelklikte op de .exe om te zien wat er zou gebeuren en het vertelde me dat ik 4.5 moest installeren….
Dus ik degradeerde naar 4.0 en het werkte!
Zorg er dus voor dat uw versies overeenkomen. Het draaide prima op mijn dev-box, maar de server had een oudere .NET-versie.
Antwoord 19
We hadden hetzelfde probleem in .NET core. De oplossing was om 32-bits .netcore runtime te downloaden en uw projectdoel x86
Voeg toe aan uw csproj-bestand
<PropertyGroup>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<PropertyGroup>
<RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>
</PropertyGroup>
Dit werd gebruikt voor een Windows-machine, je zou paden en dergelijke moeten aanpassen voor Linux/OSX
Antwoord 20
Als u onbeheerde DLL importeert, gebruik dan
CallingConvention = CallingConvention.Cdecl
in uw DLL-importmethode.
Antwoord 21
In mijn geval had ik niet het juiste project ingesteld als opstartproject. Ik ging naar de oplossingsinstellingen en selecteerde het juiste opstartproject en het werkte
Antwoord 22
In mijn geval trad dezelfde fout op na publicatie. Ik had eerder gepubliceerd met een andere platformconfiguratie.
De oplossing was om eerst de publicatiemap op te schonen, daarna werkte het.
(stel de optie “bestaande bestanden verwijderen” ook in op true)