[ungelöst] Anwendung startet mal, mal nicht

Nachdem ich in der Suche keinen passenden Beitrag gefunden habe, erstelle ich ein Thema im passenden Forum mit einem aussagekräftigen Titel sowie einem verständlich formulierten Beitrag. Ich gebe die genaue Fehlermeldung oder den genauen Text der Exception an und poste die Codezeile, in der der Fehler aufgetreten ist.

Da ich keine Fehlermeldung habe und auch keinen Code dazu, und auch nicht weiß wo der Fehler liegt, weiß ich auch nich wo ich hinposten soll, also hab ich das Sub hier genommen 0o.

Ich habe ein Programm geschrieben, welches ich bald offiziell releasen möchte.
Da ich nix release bevor es von mindestens 10 Leuten getestet wurde, hab ich das Programm einigen Freunden geschickt.

Der Hammer ist, bei manchen funktioniert es genau wie bei mir einwandtfrei, alles klappt, alles geht, und sogar so wie es geplant war, dann jedoch gibts Leute, die bekommen auf einmal exceptions, das irgendwelche Assemblies nicht gefunden werden können, obwohl alle Verweise korrekt sind und sich die Assembly im Anwendungsordner befindet.

Wieder andere Leute starten das Programm, es erstellt 3 Ordner und extrahiert eine Datei in einen dieser Ordner (läuft also definitiv), aber danach tut sich nix mehr. Da das Programm diesen Vorgang durchführt bevor die GUI erscheint, sieht der User also garnix, ausser dass 3 Ordner + 1 Datei erstellt wurden.
Hier wird keine Exception geworfen, das Programm stürzt nicht ab und läuft einfach fröhlich weiter... Endlosschleifen sind meines Wissens nach nicht möglich...

Woran kann das liegen das mein Programm sich auf System A 'so', auf System B 'so' und auf System c wieder anders verhällt?

Hallo DNAofDeath,

meine Kristallkugeln geben auch keine Auskunft warum das bei deiner Anwendung so ist.

Sind dir genauen Fehlermeldungen die beim Testen bei deinen Freunden gekommen sind vorhanden?
Hast du das Programm instrumentiert - also alles mögliche getract? Wenn dir das nix sagt siehe A Tracing Primer - Part I.
Stehen Meldungen im Event-Log von Windows?
Hast du das AppDomainUnhandeldException-Ereignis registriert und im Handler die Fehlermeldung protokolliert?
usw.

Du kannst auch wie in [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden beschrieben vorgehen. Bereite ein paar "Mini-Anwendung" gem. Tutorial vor und bitte deine Freunde zu prüfen bis zu welchem Stand die Anwendung noch einwandfrei funktioniert.

Wenn du Zugriff zu IntelliTrace hast - benötigt VS 2010 Ultimate - kannst du die Anwendung wie in Use IntelliTrace without Visual Studio .NET beschrieben "debuggen".

mfG Gü

Hast du vllt gegen das komplette .Net4 framework kompiliert? und nicht gegen das "client profile"? Das würde es zumindest Verhalten A erklären...

Weil normalerweise nur das client framework installiert ist.

Hallo DNAofDeath,

siehe auch .EXE läuft auf Entwicklungsrechner, aber nicht auf anderem PC.

herbivore

Das 'lustige' ist, ich habe hier 5 Computer zum testen. Einen Laptop mit WinXP(x86), einen Desktop mit Win7(x86), einen Desktop mit Win7(x64), einen Desktop mit WinXP(x86) und ein Netbook mit Win7(x86), auf ALLEN Rechnern LÄUFT mein Programm OHNE jegliche Komplikationen...

Ich werd noch wahnsinnig...

Das Programm ist fürs .Net Client Profile compiliert, das hab ich als erstes gecheckt nachdem mir diese Fehlermeldung gezeigt wurde.
Der Witz ist aber, es handelt sich um eine Assembly die nicht Bestandteil des .NET-Frameworks ist, sondern um die 'System.Data.SQLite.dll' die ich im Programm benutze. Kann mir Jemand sagen wieso eine Korrekt eingebundene dll auf manchen PCs nicht vom Programm gefunden wird?

@herbivore und gfoidl
Das Programm wird nicht beendet, und es wirft auch keine Exception, es läuft ja, was man an der Erstellung der Ordner sehen kann...

Das mit dem Tracing sieht interessant aus, ich weiß jedoch nicht wie ich auf einem Fremden PC einen Trace auslesen soll, und das sind zum Teil Leute die nichtmal wissen wie man ne DVD brennt...
Btw. das sieht mir alles ziemlich kompliziert aus (vom Aufwand her), kann ich nich einfach ne eigene Traceklasse schreiben die den ganzen Kram zeilenweise in ne Textdatei 'trace.log' schreibt? Das wär ne Sache von 10 Minuten... oder MUSS man das so machen wie da?

Stell mal bei der Dll Referenz die Option "Specific Version" auf "true" und probiere es nochmal aus.

Hallo DNAofDeath,

kann ich nich einfach ne eigene Traceklasse schreiben die den ganzen Kram zeilenweise in ne Textdatei 'trace.log' schreibt? Das wär ne Sache von 10 Minuten

Was denkst du was die Trace-Klassen von .net machen?

und es wirft auch keine Exception, es läuft ja, was man an der Erstellung der Ordner sehen kann...

Es kann ja danach auch einen Fehler erzeugen der irgendwo durch ein "unsachgemäßen" catch verschluckt wird. Tue in jedes catch mal ein Trace.WriteLine.

Und das Trace-File ist eine Text-Datei (beim TextWriterTraceListener) und das sollte wohl jeder der mit einem PC umgehen kann per Email versenden können. Sonst musst es dir halt persönlich von den Freunden die die Anwendung testen abholen.

Ist die Anwendung mit x86 oder x64 kompiliert? Im Zweifel nimm x86.

mfG Gü

Ich kenne das Problem - ich habe es auch gehabt.

Es gibt eine 64 bit und 32 bit Version der dll (da kommste auch net drumherum, weils auf unmanaged APIs zugreift, wenn ich mich recht erinnere). Auf deinen Entwicklungsrechnern funktioniert es, weil die verschiedenen Versionen im GAC sind, aber auf den anderen nicht, weil du entweder die 32 bit Version auf 64 bit ausführen willst oder umgekehrt.

Zwei Möglichkeiten:

1. Mit einem Installer richtig ins GAC schreiben
2. Ohne Installer eine 32 bit und eine 64 bit Version mit der entsprechenden DLL anbieten.

Ja danke für die Tipps, ich werd jetzt erstmal meinen Code mit lauter Traces versehen, danach kann man weiterschauen, evtl. zeigt mir das ja wo der Fehler passiert.

@gfoidl ich kompiliere eig. immer für x86, weil nicht jeder nen x64 pc hat, aber x86 Programme eben auf diesen auch laufen aber nicht umgekehrt... ausserdem muss mein Programm sicher nicht mehr als ~3,5GB RAM addressieren xD

@Femaref
Ich habe keine Probleme die Architekturbedingt sind, ich schrieb bereits:

Das 'lustige' ist, ich habe hier 5 Computer zum testen. Einen Laptop mit WinXP(x86), einen Desktop mit Win7(x86), einen Desktop mit Win7(x64), einen Desktop mit WinXP(x86) und ein Netbook mit Win7(x86), auf ALLEN Rechnern LÄUFT mein Programm OHNE jegliche Komplikationen...

Es liegt also definitiv nicht an x86/x64, zumal alle x86 Assemblies unter x64 problemlos funktionieren sollten, mir ist jedenfalls nicht bekannt wieso nicht...

Ich meld mich dann wenn ich weiß worans lag...

@Femaref es liegt wohl doch an der Architektur, ich hatte nicht bedacht, dass die x64 Maschine mein Entwicklungsrechner ist xD

Die Frage ist jetzt, woher bekomme ich eine fertigkompilierte x64 System.Data.SQLLite.dll? Ich finde nämlich keine, bzw. wenn ich eine finde, und mein gesamtes Projekt für x64 kompiliere findet mein Programm die dll trotzdem nicht. Ich hab mir den Source geladen, aber wie ich das kompilieren soll... kein Plan, da sind tausend Batchdateien und man muss 1 Mio Sachen beachten überfodert.

(Kannst mir vielleich per pn die geben die du verwendest? Dann weiß ich wenigstens sicher das es die richtige ist...)

Und gibt es einen weniger umständlichen weg, als jedesmal in den Verweisen die x86 dll rauszunehmen und die x64 einzubinden, für x64 zu kompilieren, und das ganze Spiel wieder rückwärts? Das nervt nämlich...

Kann man dlls auch im GAC ohne Installer registrieren? Wenn ich nämlich nen Installer erstelle, funktioniert das Programm überhauptnicht mehr und da ich keinen Installer geplant habe will ich mich auch ungern tagelang damit beschäftigen (mein Programm muss bis zum 15. lauffähig sein und am 01.08 muss es offiziell an den Start gehen...).

Ich hab versuch die dll in C:/Windows/assemblys zu kopieren, aber das geht nicht, wieso auch immer... (Jemand nen Grund dafür parat?)

Wenn ich das nicht schaffe, dann muss ich ne Abfrage beim Start machen ob ein x86 System vorliegt, wenn nicht --> Meldung 'Das Ding hier läuft nur unter x86 Betriebssystemen' finde sowas kacke (aus Anwendersicht).

Hallo DNAofDeath,

Und gibt es einen weniger umständlichen weg, als jedesmal in den Verweisen die x86 dll rauszunehmen und die x64 einzubinden, für x64 zu kompilieren, und das ganze Spiel wieder rückwärts? Das nervt nämlich...

Das Thema wurde schon einige Male besprochen. Bitte benutze die Forumssuche und poste die besten Treffer hier. Vielen Dank!
ZB [erledigt] 2 DLLs in verschiedenen Versionen einbinden und 32bit/64bit - unterschiedliche DLL einbinden.

Kann man dlls auch im GAC ohne Installer registrieren?

Ja - siehe unten.

Ich hab versuch die dll in C:/Windows/assemblys zu kopieren

Ab .net 4.0 ist der GAC woanders. C:\WINDOWS\Microsoft.NET\assembly und da kannst du die Assemblies auch selbst reinkopieren. Schau dir einfach an wie die bestehenden Assemblies da drin angelegt sind und mach das selbst auch - auf den PublicKeyToken achten (den bekommst du mit sn.exe). ngen kann/soll auch angewandt werden. Das geht dann nciht automatisch. Mehr macht gacutil.exe afaik auch nicht. Dieses ist zwar nur exe + config ob es aber mitverteilt für die Intallation werden darf weiß ich nicht.

mfG Gü

DNA: Die x64 dll liegt im System.Data.Sqlite Ordner unter x64.

Ich hab mir dafür einfach mehrere Configurations gebaut, die dann mit nem post-build event dann einfach die entsprechende dll ins output kopieren.

Also ich bin am Ende mit meinem Latein... nach 6 Stunden probieren & recherchieren...

Ich kompiliere für x86, bette die x86 dll ein, versuche es in einer VM mit Win7 x86 zum Laufen zu bringen: Kann die dll nicht finden.
(Ebenfalls: Ich versuche es in einer x64 Win7 VM zum Laufen zu bringen: Kann die dll nicht finden.)

Aufm entwicklungsrechner läuft es jedoch...

Ich werd hier langsam wahnsinnig... ich hab schon ALLES was in meinem Projekt auf x86 einstellbar ist, auf x86 eingestellt, was soll ich denn sonst noch tun?

Des Weiteren registriere ich die Assembly bei jedem Programmstart(is das überhaupt jedes Mal nötig?) im GAC mit folgendem 2Zeiler:

            System.EnterpriseServices.Internal.Publish p = new System.EnterpriseServices.Internal.Publish();
            p.GacInstall("System.Data.SQLite.dll");

Ich habs überprüft, die DLL erscheint im Ordner 'C:\Windows\Microsoft.NET\assembly\GAC_32', was ja auch so sein soll...

Es kommt immer und immer wieder die Meldung, völlig egal in welcher VM ich das teste:> Fehlermeldung:

System.IO.FileNotFoundException: Die Datei oder Assembly "System.Data.SQLite.dll" oder eine Abhängigkeit davon wurde nicht gefunden. Das angegebene Modul wurde nicht gefunden.
Dateiname: "System.Data.SQLite.dll"
bei
.
..()
bei
.
..()
bei
.
..
()

Ich bin langsam ernsthaft am überlegen, ob ich das mit dem SQLite-Kack nich komplett streiche, und stattdessen einfach ne CSV, ne XML oder direkt die Anwendungseinstellungen nehme, was aber nich annähernd so hübsch wäre wie ne SQLite-DB -.-* (Meine Meinung...).

Helft mir, ich hab alles probiert was hier vorgeschlagen wurde (sogar die Trial von nem 3000$ teuren 'Installer Studio' geladen und damit ne Installation erstellt... ohne brauchbare Ergebnisse)...

Hallo DNAofDeath,

ist die "SQLite.Interop.dll" ebenfalls vorhanden? Hast du die Exception bis auf die Root-Exception (.InnerException Property rekursiv) durchsucht? Was sagt diese?

spooky

Guten Morgen,

Die SQLite.Interop.dll Assembly muss in das Root-Verzeichnis des Projektes, welches die System.Data.SQLite.dll Assembly nutzt. Die SQLite.Interop.dll Assembly stellst du unter den Eigenschaften auf "Copy Always"

hier mal das Original

Zitat von: System.Data.SQLite: View Ticket: Unable to load DLL SQLite.Interop.DLL ...
anonymous added on 2011-04-27 20:18:17 UTC:
Kribo

So conclusion .. When one makes a dotNet appi using embedded SQLite. One must add an "existing item" to your project. And this directly uder the root MySolution MyProject SQLite.Interop.DLL

And one must ulter the property of the item "SQLite.Interop.DLL" Copy to Output Directory -> Copy always

And "System.Data.SQLite.dll" one adds as a reference to ones project..

After doing so your appi should run..

Kind regards

Kribo

Und wenn du eine x86 bzw. x64 Anwendung erstellen willst so guck dir die Links von gfoidl näher an

Danke für den Hinweis, ich glaube jetzt bin ich schonmal ein Stück weiter gekommen, aber es kommt immernoch eine Exception -.-*

Fehlermeldung:
System.DllNotFoundException: Die DLL "SQLite.Interop.DLL": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
bei System.Data.SQLite.UnsafeNativeMethods.sqlite3_open_interop(Byte[] utf8Filename, Int32 flags, IntPtr& db)
bei System.Data.SQLite.SQLite3.Open(String strFilename, SQLiteOpenFlagsEnum flags, Int32 maxPoolSize, Boolean usePool)
bei System.Data.SQLite.SQLiteConnection.Open()
bei
.
..
()
bei
.
..()
bei
.
..()
bei
.
..
()

@Spook: Exception.InnerException ist null...

Das ist jetzt auf der Win7 x86 VM... alle Dateien liegen auf dem Desktop also im gleichen Verzeichnis... (ja, auch die interop dll)

Gebe ich den Fehler bei Google ein, bekomme ich nur 2 unbrauchbare Ergebnisse...

[nebenbei]Zum deployment für verschiedene Systeme, das hier hört sich interessant an:
Using Side-by-Side assemblies to load the x64 or x32 version of a DLL, das werde ich ma ausprobieren...
Wobei ich das ja im Moment garnicht will... ich will nur ne x86-Version zum Laufen bringen xD[/nebenbei]

//EDIT

Ich habe jetz auf der Entwicklungsmaschine ALLE Eingetragenen dlls aus dem GAC gelöscht.
In den GAC_MSIL wird die dll jedoch automatisch reingewofen beim Erstellen...
Jeoch bekomme ich jetzt einen weitaus detaillierten Fehler angezeigt:> Fehlermeldung:

---

---

System.IO.FileNotFoundException: Die Datei oder Assembly "System.Data.SQLite, Version=1.0.74.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Dateiname: "System.Data.SQLite, Version=1.0.74.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139"

bei
.
..()

bei
.
..() in C:\Users\SkyNET\Documents\Visual Studio 2010...\Forms\frmMain.cs:Zeile 367.

bei
.
..
() in C:\Users\SkyNET\Documents\Visual Studio 2010...\Forms\frmMain.cs:Zeile 60.

=== Zustandsinformationen vor Bindung ===

LOG: Benutzer = Cyberdyne\SkyNET

LOG: DisplayName = System.Data.SQLite, Version=1.0.74.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139
(Fully-specified)

LOG: Appbase = file:///C:/Users/SkyNET/Documents/Visual Studio 2010/.../Debug/

LOG: Ursprünglicher PrivatePath = NULL

Aufruf von Assembly : ***, Version=0.0.0.1, Culture=neutral, PublicKeyToken=null.

===

LOG: Diese Bindung startet im default-Load-Kontext.

LOG: Die Anwendungskonfigurationsdatei wird verwendet: C:\Users\SkyNET\Documents\Visual Studio 2010...\bin\Debug[...].exe.Config

LOG: Die Hostkonfigurationsdatei wird verwendet:

LOG: Die Computerkonfigurationsdatei von C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config wird verwendet.

LOG: Verweis nach der Richtlinie: System.Data.SQLite, Version=1.0.74.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139

LOG: Die gleiche Bindung ist bereits aufgetreten und hat den Fehler hr = 0x80070002 verursacht.

---

OK

Was mich hier beunruhigt ist
'LOG: Ursprünglicher PrivatePath = NULL'
Was soll das heißen? Dass der Pfad zu der dll nicht angegeben wurde?

Wenn ich nach dem Erscheinen dieses Fehlers das Programm nochmal debugge kommt der Fehler nicht mehr (was daran liegen mag das VS die Assembly in den GAC_MSIL schmeißt).

Wenn bis 23 Uhr hier keine weitere Antwort kommt, gebe ich den K(r)ampf auf und benutze irgendwas Anderes zum Speichern der Daten, als diesen nicht funktionierenden Mist...

//EDIT2

Okay, ich scheiß drauf, ich mach alles in ne XML-Datei, is sowieso einfacher...