2012-07-10 3 views
5

Ich versuche, eine zusammengeführte Version von FakeItEasy zu erstellen, die Castle.Core enthält. Ich habe über ILMerge gelesen und es schien, als wäre es die Lösung, die ich brauchte. Nach dem Herunterladen und Erstellen von FakeItEasy kopierte ich alle benötigten Dateien (FakeItEasy.dll (.NET4), Castle.Core.dll (.NET4), ilmerge.exe, FakeItEasy.snk) in den gleichen Ordner. Ich lief dann den folgenden Befehl ein:Erstellen von signierten Bibliothek mit ILMerge werfen Ausnahme

ilmerge 
    /keyfile:FakeItEasy.snk 
    /out:..\FakeItEasy.dll 
    /t:library 
    /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 
    FakeItEasy.dll Castle.Core.dll 

Und bekam folgendes Ergebnis:

An exception occurred during merging:                
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)                         
    at System.Compiler.Writer.MscorsnStrongNameSignatureGeneration(String wszFilePath, String wszKeyContainer, Byte[] pbKeyBlob, Int32 cbKeyBlob, IntPtr ppbSignatureBlob, IntPtr pcbSignatureBlob) 
    at System.Compiler.Writer.WritePE(String location, Boolean writeDebugSymbols, Module module, Boolean delaySign, String keyFileName, String keyName)            
    at System.Compiler.Writer.WritePE(CompilerParameters compilerParameters, Module module)   
    at ILMerging.ILMerge.Merge()                 
    at ILMerging.ILMerge.Main(String[] args) 

Wenn ich die „/keyfile:FakeItEasy.snk“ die fusionierte Baugruppe erstellt wegzulassen ist ganz gut, aber das hilft mir nicht, da ich eine signierte Version brauche.

Ich habe auch versucht, die Zielplattform spezifiziert als:

/targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 

aber die Ergebnisse waren die gleichen.

+1

Hey, hast du eine Antwort darauf gefunden, da ich das gleiche Problem habe. – Confused

+0

Ich habe es nie herausgefunden. Am Ende haben wir die Version von FakeItEasy verwendet, die über NuGet verteilt wurde, so dass das Problem wegfiel. –

+0

Ein Workaround, der für mich funktionierte, war "corflags ilmerge/32bitreq +/force", damit es im 32-Bit-Modus statt im 64-Bit-Modus ausgeführt wird. – jnm2

Antwort

2

Ich habe dieses Problem kürzlich beim Einrichten eines Projekts auf einem neuen Computer mit Windows 8 64-Bit. Ich habe zuvor in einer virtuellen 32-Bit-Windows-7-Maschine entwickelt und hatte kein Problem. Der ILMerge-Befehl wird als Post-Build-Ereignis ausgeführt. Da Visual Studio ein 32-Bit-Prozess ist, konnte ich das Verhalten auch in einer 32-Bit Visual Studio-Eingabeaufforderung auf der Windows 8 64-Bit-Maschine mit demselben ILMerge-Befehl replizieren, der im Post-Build-Ereignis verwendet wurde.

ILMerge.exe 
    /keyfile:public.snk 
    /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" 
    /t:exe 
    /ndebug 
    /out:Result.exe Source.exe Other.dll 

Ich habe eine Menge Arbeit Schnittstelle .NET-Anwendungen durchgeführt und native C++ Bibliotheken, also bin ich sehr vertraut mit der Ausnahmemeldung An attempt was made to load a program with an incorrect format. Dies deutet auf eine Bitness Problem, bei dem zum Beispiel ein 32-Bit Prozess versucht, eine 64-Bit-Bibliothek zu laden. Genau diese Situation geht hier meiner Meinung nach vor sich. Da dies eine 64-Bit-Maschine ist, habe ich auch den Befehl ILMerge in einer 64-Bit Visual Studio-Eingabeaufforderung versucht. Interessanterweise, aber nicht völlig überraschend, funktioniert derselbe Befehl, der die Ausnahme in der 32-Bit-Eingabeaufforderung erzeugt, in der 64-Bit-Eingabeaufforderung einwandfrei.

Ich verwende eine Snk-Datei, die nur öffentliche Schlüsselinformationen bei der Entwicklung enthält, also verzögere ich die Signierung der zusammengeführten Baugruppe. Ich schaute dann auf die verfügbaren Befehlsschalter für ILMerge und entdeckte den /delaysign Schalter. Durch Hinzufügen dieses Schalters zum ILMerge-Befehl wird das Problem beim Ausführen von ILMerge aus einem 32-Bit-Prozess behoben.

ILMerge.exe 
    /keyfile:public.snk 
    /delaysign 
    /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" 
    /t:exe 
    /ndebug 
    /out:Result.exe Source.exe Other.dll 

Was noch interessanter ist, dass, wenn eine snk-Datei mit einem vollständigen öffentlichen/privatem Schlüsselpaar verwendet, der ILMerge Befehl ohne die /delaysign Schalter ganz gut funktioniert. Es scheint also, dass die Ausnahme generiert wird, wenn eine Snk-Datei mit nur öffentlichen Schlüsselinformationen verwendet wird und wenn ILMerge von einem 32-Bit-Prozess gestartet wird.

0

Ich fing an, diesen Fehler zu erhalten, wenn ich auf VS 2015 von VS 2013 aktualisierte und versuchte, ein Projekt zu bauen, das immer gut gebaut hatte (ILMerge wird als Teil des Baus ausgeführt). Die obige Antwort hat mich daran erinnert, dass private Schlüssel administrativen Zugriff benötigen. Dann erinnerte ich mich, dass meine neue VS 2015-Verknüpfung nicht auf "Als Administrator ausführen" eingerichtet wurde. Nach dem Neustart von VS 2015 als Administrator funktionierte der ILMerge-Teil des Builds einwandfrei.

Verwandte Themen