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.
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 )
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.
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.
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.
Falls es jemandem hilft, konnte ich dieselbe Ausnahme mit diese Antwort auf eine ähnliche Frage beheben, aber ich bekam keine Ausnahme von installutil.exe.
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-bit
unter dem Abschnitt Plattformziel war standardmäßig aktiviert. Dies war das Problem und funktionierte einwandfrei, nachdem die Option Prefer 32-bit
deaktiviert wurde.
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.
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.
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.
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.
Ich hatte dieses Problem mit einem WinForms-Projekt unter Verwendung von VS 2015. Meine Lösung war:
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.
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.
Der Schlüssel besteht darin, Match-Prozessor-Einstellungen für das Projekt festzulegen, die sich an zwei Stellen befinden.
Stellen Sie außerdem sicher, dass die Einstellungen für die ArchTecuture im Menü Test >> Test Settings >> Default Processor Archtecture >> (siehe unten) identisch sind.
Dies gilt für VS2013, möglicherweise jedoch auch für andere Versionen.