it-swarm.com.de

System.BadImageFormatException: Datei oder Assembly konnte nicht geladen werden (von installutil.exe)

Ich versuche, einen Windows-Dienst mit InstallUtil.exe zu installieren, und erhalte die Fehlermeldung

System.BadImageFormatException: Datei oder Assembly '{xxx.exe}' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

Was gibt?


BEARBEITEN: (nicht nach OP) Vollständige Nachricht aus dup extrahiert, um noch mehr Treffer zu erhalten [für googleability]:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319> InstallUtil.exe C:\xxx.exe Microsoft (R) .NET Framework-Installationsprogramm Version 4.0.30319.1 Copyright (c) der Microsoft Corporation. Alle Rechte vorbehalten.

Beim Initialisieren der Installation ist eine Ausnahme aufgetreten: System.BadImageFormatException: Die Datei oder die Assembly 'file: /// C:\xxx.exe' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

89
Epaga

Stellen Sie sicher, dass das neueste Framework (das, mit dem Sie Ihre App kompiliert haben) zuerst im PFAD ist. Das hat das Problem für mich gelöst. (Gefunden in einem Forum )

15
Epaga

Einige Details zur Vollständigkeit, falls es jemandem hilft ...

Beachten Sie, dass der häufigste Grund für diese Ausnahme heutzutage der Versuch ist, ein 32-Bit-spezifisches (/platform:x86) DLL in einen 64-Bit-Prozess zu laden oder umgekehrt (dh ein 64-Bit-spezifisches (/platform:x64) DLL in einen 32-Bit-Prozess). Wenn Ihre platform unspezifisch ist (/platform:AnyCpu), wird dies nicht auftreten (vorausgesetzt, dass keine referenzierten Abhängigkeiten die falsche Bittigkeit haben).

Mit anderen Worten:

% windir%\Microsoft.NET\Framework\v2.0.50727\installutil.exe 

oder:

% windir%\Microsoft.NET\Framework64\v2.0.50727\installutil.exe 

funktioniert nicht (ersetzen Sie es in anderen Framework-Versionen: v1.1.4322 (nur 32-Bit, daher tritt dieses Problem nicht auf) und v4.0.30319 wie oben beschrieben.

Wie in der anderen Antwort beschrieben, benötigt man natürlich auch die .NET-Versionsnummer der installutil, die Sie ausführen, um> = (vorzugsweise =) der EXE-/DLL-Datei zu sein, in der Sie das Installationsprogramm ausführen.

Beachten Sie schließlich, dass in Visual Studio 2010 standardmäßig x86-Binärdateien ( und nicht Any CPU wie zuvor ) generiert werden.

Vollständige Details zu System.BadImageFormatException (Die einzige Ursache ist die Nichtübereinstimmung von Bittingness ist wirklich eine grobe Vereinfachung!).

Ein weiterer Grund für eine BadImageFormatException unter einem x64 -Installer ist, dass in Visual Studio 2010 der Standardtyp .vdproj Install Project ein 32-Bit-InstallUtilLib-Shim generiert, sogar auf einem x64-System (Search for Msgstr "Verwaltete benutzerdefinierte 64 - Bit - Aktionen lösen eine System.BadImageFormatException - Ausnahme" auf der Seite aus.

134
Ruben Bartelink

Ich denke, Sie verwenden die 64-Bit-Version des Tools, um eine 32-Bit-Anwendung zu installieren. Ich bin heute auch mit diesem Problem konfrontiert und habe diesen Framework-Pfad dazu genutzt.

C:\Windows\Microsoft.NET\Framework\v4.0.30319

und es sollte Ihre 32-Bit-Anwendung gut installieren.

9
Sachin Kalia

OK, dies ist das Problem, das ich hatte, und was es behoben hat, scheint für das oben Genannte sehr relevant zu sein.

Ich verwende Visual Studio 2010 Express. Ich habe einen Test-Service geschrieben, der eigentlich nichts getan hat. Es war später nur noch Übung für die eigentliche Sache. 

Ich habe den Dienst geschrieben und versucht, ihn mit installutil.exe zu installieren. Folgende Fehlermeldung wurde angezeigt:

System.BadImageFormatException: Datei oder Assembly '{filename.exe}' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

So weit wie der ursprüngliche Autor. 

Rubens Beobachtung Über die 32-Bit-Ausgabe von Visual Studio 2010 war hier der Retter. 

Ich habe die 64-Bit-Version von installutil.exe verwendet. Die Ausgabe des Visual Studio 2010-Builds war zwar 32-Bit. Um nur einen kleinen Mehrwert hinzuzufügen, finden Sie die 32-Bit-Version des neuesten .NET-Frameworks und den zugehörigen installutil.exe im Ordner C:\Windows\Microsoft.NET\framework. Mit dieser Version von installutil.exe wurde mein Problem behoben. Der Service wurde ohne Probleme installiert!

Ich hoffe, das hilft jemandem da draußen. 

6
James Crowther

Falls es jemandem hilft, konnte ich dieselbe Ausnahme mit diese Antwort auf eine ähnliche Frage beheben, aber ich bekam keine Ausnahme von installutil.exe.

1
Joseph Snow

Ich habe dieses Problem heute konfrontiert. In meinem Fall wurde das (hatte einen Verweis auf eine 64-Bit-DLL) meiner Anwendung Plattformziel auf AnyCPU gesetzt, aber das Kontrollkästchen Prefer 32-bitunter dem Abschnitt Plattformziel war standardmäßig aktiviert. Dies war das Problem und funktionierte einwandfrei, nachdem die Option Prefer 32-bit deaktiviert wurde.

0
mabiyan

Nachdem ich alle genannten Lösungen ausprobiert hatte, fand ich die PlatformTarget-Konfiguration irgendwie in der AnyCPU-Konfiguration in meinem Projekt .csproj.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>Prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Das Entfernen der Leitung funktionierte für mich.

0
SohamC

Ich hatte das gleiche Problem. Ich benutze den Standardbefehl zur Ausführung. Es war der X64 Ro-Run gegen X86-Tests. Ich musste die X86 und nicht die X64-Version des Nunit-Runner angeben.

0
dermot kirk

Mein Problem war anders. Dies trat nach einem unerwarteten Herunterfahren meines Windows 7-Computers auf. Ich habe eine saubere Lösung durchgeführt und es lief wie erwartet.

0
GregN

Target Build x64 Zielserver-Hosting IIS 64 Bit

Klicken Sie mit der rechten Maustaste auf appPool-Hosting, auf dem die Website/Webanwendung ausgeführt wird, und setzen Sie die 32-Bit-Anwendung Enable auf false.

 enter image description here

0
VK_217

Zusammenfassend müssen sowohl Build als auch Project\Build\Platform auf x64 gesetzt sein, um den 64-Bit-Dienst auf einem 64-Bit-System erfolgreich installieren zu können.

0
Daniel D

Ich hatte dieses Problem mit einem WinForms-Projekt unter Verwendung von VS 2015. Meine Lösung war:

  1. klicken Sie mit der rechten Maustaste auf das Projekt
  2. eigenschaften auswählen
  3. aktivieren Sie "32-Bit bevorzugen".
  4. Plattformziel: Jede CPU
0
Michael Staples

Wir haben eine andere Lösung für ein Problem mit demselben Symptom gefunden:

Wir haben diesen Fehler gesehen, als wir das Projekt von .net 4.7.1 auf 4.7.2 aktualisiert haben.

Das Problem bestand darin, dass, obwohl wir im Projekt nicht mehr auf System.Net.Http verweisen, dies im dependentAssembily-Abschnitt unserer web.config aufgeführt war. Das Entfernen dieser und anderer nicht verwendeter Assemblyverweise aus der web.config löste das Problem.

0
Logan

Wenn diese Nachricht in Live-Tests, aber nicht in Komponententests vorhanden ist, liegt dies daran, dass ausgewählte Baugruppen schnell nach $(SolutionDir)\.vs\$(SolutionName)\lut\0\0\x64\Debug\ kopiert werden. Manchmal können jedoch nur wenige Assemblys nicht ausgewählt werden, z. B. VC++ - DLLs bei Interop-C++/c # -Projekten.

Nach dem Erstellen von xcopy wird das Problem nicht behoben, da die kopierte Datei von der Live-Test-Engine gelöscht wird.

Die einzige bisherige Problemumgehung (28 dez 2018) besteht darin, Live-Tests zu vermeiden und alles in Unit-Tests mit dem Attribut [TestCategory("SkipWhenLiveUnitTesting")] für die Testklasse oder die Testmethode auszuführen.

Dieser Fehler tritt in allen Visual Studio 2017-Versionen bis 15.9.4 auf und muss vom Visual Studio-Team behoben werden.

0
Soleil

Der Schlüssel besteht darin, Match-Prozessor-Einstellungen für das Projekt festzulegen, die sich an zwei Stellen befinden.

 enter image description here 

Stellen Sie außerdem sicher, dass die Einstellungen für die ArchTecuture im Menü Test >> Test Settings >> Default Processor Archtecture >> (siehe unten) identisch sind.

 enter image description here 

Dies gilt für VS2013, möglicherweise jedoch auch für andere Versionen.

0
zar