none
'Der Typeninitialisierer für xxx.Modul1 hat eine Ausnahme verursacht' RRS feed

  • Frage

  • Unter VS2010 verusche ich ein bestehendes Porjekt weiter zu entwickeln.

    Obige Fehlermeldung erhalte ich jetzt beim versuich die Anwendung (Konsolenanwednung) zu starten.

    Das Projekt wurde ursprünglich auf einem anderen Rechner entwickelt, wahrscheinlich mit 32-bit VS2008.

    Der jetzige Rechner ist 64-Bit Windows 7 mit VS2010

    Im Internet habe ich zwar einige Leidtragende gefunden, aber keine Lösung dazu.

     

    Donnerstag, 5. Mai 2011 13:12

Antworten

  • Hallo Nico,

    eine BadImageFormatException tritt dann auf, wenn die gefundene DLL vom falschen Prozessortyp ist
    (oder anderweitig beschädigt, was aber die Ausnahme sein dürfte).
    Das kann dann an x86 / x64 liegen.
    Da es sich offensichtlich um eine COM-DLL (Interop) handelt,
    muss sich der CPU-Typ daran ausrichten.

    Die von Dir gefundene Zeile könnte daran scheitern, dass der Zugriff auf die
    Hauptverzeichnisse (C:\) unter Vista/Windows 7 beschränkt ist.
    Dann schlägt das Erstellen fehl. Und weil ein Modul letztendlich eine Klasse ist
    passiert das Öffnen im statischen Konstruktor, was wiederum das gesamte Modul lahmlegt.

    Deswegen:
    Dateien sollte man nicht dauerhaft öffnen (und hier am besten auf ein Modul verzichten),
    sondern nur bei Bedarf (und danach direkt wieder schliessen).

    Temporäre/Hilfs-Dateien erstelle in einem öffentlichen/temporären Verzeichnis.
    Für oben könnte das sein:

    Dim fs As New System.IO.FileStream( _
       Path.Combine(Path.GetTempPath(), "test.txt"), _
       FileMode.Create, FileAccess.Write)
    
    Gruß Elmar

    Freitag, 6. Mai 2011 14:50

Alle Antworten

  • Hallo Nico,

    ohne mehr darüber zu wissen, was in dem Programm passiert, kann man wenig dazu sagen.
    Ob ein Programm zuvor mit VS 2008 entwickelt wurde, hilft dabei nicht weiter.
    Wichtiger: Welche Komponenten werden von dem Programm verwendet?

    Der Typinitialisierer wäre der statische Konstruktor (bei Visual Basic auch Module).
    Tritt dort eine Ausnahme auf, so kann der Typ nicht verwendet werden
    (und das Programm endet).

    Ein Versuch wäre:
    Stelle unter CPU Typ x86 ein, das vermeidet Probleme wenn (unmanaged) 32-Bit Bibliotheken eingebunden sind.

    Überprüfe welche Bibliotheken von dem Programm verwendet werden.

    Gruß Elmar

    Donnerstag, 5. Mai 2011 20:44
  • Ich werde es mal probieren.

    Die Anwendung macht eigentlich im Wesentlichen Gebrauch vom DDBAC HBCI-Banking - möglicherweise ist das die Ursache. Selbst wenn ich das Debuggen mit F11 starte kommte es noch nicht mal bis zur ersten Programmzeile.

    Der Rest sind ADO.NET-geschichten, die dürften ja wohl mit 32 und 64-Bit laufen.

    Reicht es als CPU-Typ x86 einzustellen ?

    Die Anwednung funktioniert ja bereits seit langem und läuft täglich unbeaufsichtigt auf einem Win 2008/64 Server

    Freitag, 6. Mai 2011 06:24
  • Hallo Nico,

    statische Konstruktoren werden sehr früh aufgerufen, nämlich wenn der Typ (Klasse/Modul) zum ersten Mal angesprochen wird.
    Greift man dort auf etwas zurück was nicht vorhanden ist, funktioniert ist sofort Ende der Schicht.

    ADO.NET läuft nur dann unabhängig von vom CPU-Typ wenn die Provider rein managed (in .NET geschrieben) sind.
    Verwendest etwas wie OleDb (klassisch der Access/Jet) Provider stimmt das nicht mehr.

    Der Tipp mit dem CPU-Typ ziel auf Komponenten, die nur unter 32-Bit verfügbar sind.

    WEnn Du wiederum sagst, das Programm lief bereits unter 64-Bit,
    so dürfte eine Komponente auf Deinem neuen Rechner fehlen.

    Das Debuggen kann schwierig sein, wenn Du z. B. Visual Basic verwendest, da dort bereits
    einiges vor Deinem eigenen Code stattfindet (insbesondere wenn das Application Framework aktiv ist).
    Deaktiviere unter den Debugging Optionen "Nur eigenen Code aktivieren" , "Eigenschaften Operatoren überspringen..."

    Um herauszufinden, ob eine Komponente fehlt, hilft sich das Fusion Log anzuschauen:
    http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx

    Gruß Elmar

    Freitag, 6. Mai 2011 10:28
  • Leider nur geringe Besserung.

    Man muss anscheinend im Konfigurations-Manager auf x86 umschalten, di Auswahl im Reiter Komplirien nutzt nichts!

    Warnung 4 Für die referenzierte obj\Debug\Interop.BankingApplicationComponents.dll-Assembly ist ein anderer Zielprozessor festgelegt als für die Anwendung. HBCI_Kontenscanner2

    Dies verschwindet dann.

    Die Fehlermeldung lautet 'Eine Ausnahme (erste Chance) des Typs "System.BadImageFormatException" ist in Unbekanntes Modul. aufgetreten.'

    Fehlende Verweise scheinen auch nicht das Thema zu sein.

    Mit den Umstellungen unter Opionen/Debugging komme ich jetzt weiter:

    Diese Zeile scheint der Übeltäter:

    Module Modul1

     Dim fs As New System.IO.FileStream("C:\test.txt", FileMode.Create, FileAccess.Write)

    ....

    Möglicherweise liegt ein simples Zugriffsporblem vor.

     

     

    Freitag, 6. Mai 2011 13:47
  • Hallo Nico,

    eine BadImageFormatException tritt dann auf, wenn die gefundene DLL vom falschen Prozessortyp ist
    (oder anderweitig beschädigt, was aber die Ausnahme sein dürfte).
    Das kann dann an x86 / x64 liegen.
    Da es sich offensichtlich um eine COM-DLL (Interop) handelt,
    muss sich der CPU-Typ daran ausrichten.

    Die von Dir gefundene Zeile könnte daran scheitern, dass der Zugriff auf die
    Hauptverzeichnisse (C:\) unter Vista/Windows 7 beschränkt ist.
    Dann schlägt das Erstellen fehl. Und weil ein Modul letztendlich eine Klasse ist
    passiert das Öffnen im statischen Konstruktor, was wiederum das gesamte Modul lahmlegt.

    Deswegen:
    Dateien sollte man nicht dauerhaft öffnen (und hier am besten auf ein Modul verzichten),
    sondern nur bei Bedarf (und danach direkt wieder schliessen).

    Temporäre/Hilfs-Dateien erstelle in einem öffentlichen/temporären Verzeichnis.
    Für oben könnte das sein:

    Dim fs As New System.IO.FileStream( _
       Path.Combine(Path.GetTempPath(), "test.txt"), _
       FileMode.Create, FileAccess.Write)
    
    Gruß Elmar

    Freitag, 6. Mai 2011 14:50