Hallo,
ich bin gerade sehr am Verzweifeln. Mein Problem:
Ich möchte einen Installer für ein Teamspeak 3 Design erstellen. Habe soweit auch alles fertig, Problem ist nur: ZIP entpacken ist nicht möglich.

Ich benutze derzeit Visual Studio Express 2012 (VB2012) und möchte deshalb die Möglichkeiten von Framework 4.5 nutzen. Ich habe in einem Beitrag gelesen, dass Framework 4.5 nun ermöglicht, ZIP Dateien zu entpacken. Nun habe ich alles soweit gemacht, nur jetzt bekomme ich eine Fehlermeldung in der Ausgabe vom Debuggen und während des Debuggens vom "Catch ex As Exception":

Eine Ausnahme (erste Chance) des Typs "System.IO.FileNotFoundException" ist in System.IO.Compression.FileSystem.dll aufgetreten.
Der Thread 'vshost.RunParkingWindow' (0x274c) hat mit Code 0 (0x0) geendet.
Der Thread '<Kein Name>' (0x2410) hat mit Code 0 (0x0) geendet.
Das Programm "[8932] TS3-Designinstaller.vshost.exe: Verwaltet (v4.0.30319)" wurde mit Code 0 (0x0) beendet.

Ich habe diese Verweise hinzugefügt: System.IO.Compression, System.IO.Compression.FileSystem.dll & shell32.dll

Mein Code sieht so aus:

Imports System
Imports System.IO
Imports Shell32
Imports System.Net
Imports System.Security
Imports System.IO.Compression

Public Class Form4

Private Sub Form4_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

'ZIP entpacken
Try
System.IO.Compression.ZipFile.ExtractToDirectory(Application.StartupPath & "zeLFClan.zip", Form3.TextBox3.Text & "\zeLFClan")

Catch ex As Exception

MsgBox("Fehler #02! Stellen Sie sicher, dass Sie über alle Administrationsrechte verfügen. Ist dies der Fall, so Kontaktieren Sie uns unter beispiel.de - Klicken Sie auf OK, um die beiden Installationsverzeichnisse zu öffnen. Bitte entpacken Sie manuell die ZIP Dateien: zeLFClan und zeLFClanICONS. Der Installer wird beendet.", MsgBoxStyle.Critical)
Process.Start(Form3.TextBox3.Text)
Process.Start(Form3.TextBox2.Text)
Application.Exit()

End Try
End Sub
End Class

Ich wäre euch sehr Dankbar, wenn ihr mir helfen könntet.
Lieben Gruß

Die Fehlermeldung sagt doch im Grunde schon alles. Das Programm konnte deine Datei nicht finden.

Das verstehe ich aber dann nicht. Ich habe den verweis nämlich per Durchsuchen hinzugefügt. Wie kann ich das Problem nun lösen, falls es das denn wirklich ist?

Nein, nicht die DLL wird nicht gefunden, sondern die ZIP-Datei die du entpacken möchtest.

Ach so, verstehe. Entschuldige den Verständnisfehler. Wüssten Sie denn, wie ich die Zeile anders schreiben könnte, oder ist diese an sich richtig?
Nachtrag: diese meine ich:
System.IO.Compression.ZipFile.ExtractToDirectory(Application.StartupPath & "zeLFClan.zip", Form3.TextBox3.Text & "\zeLFClan")

Wir sind hier im Internet, du brauchst mich nicht zu siezen.
Die Zeile an sich sieht korrekt aus, auch wenn ich die Signatur der Methode gerade nicht im Kopf habe. Aber angenommen, dass der erste Parameter die Quelldatei und der zweite der Zielordner ist, sollte das so passen. Bist du dir denn sicher, dass im Verzeichnis deiner Anwendung eine Datei namens "zeLFClan.zip" existiert?

Ja bin mir eigentlich sicher. Ich schreibe mal kurz und knapp den Ablauf den das Programm macht: Download von zeLFClan.zip, zeLFClanICONS.zip und zeLFClan.qss und werden im Startup von der Anwendung gespeichert > Installationspfad angeben: Alle Dateien werden dorthin kopiert > anschließend kommt das ZIP entpacken dran, woran es ja leider scheitert. Ich habe auch schon versucht:
System.IO.Compression.ZipFile.ExtractToDirectory(Form 3.textbox3.text & Application.StartupPath & "\zeLFClan") usw. Wenn ich nach dem Scheitern im Ordner schaue, ist dort ja auch die ZIP drin, deshalb muss die ja beim Try entpacken vorhanden sein

Versuch mal, vor den Dateinamen noch einen Backslash zu setzen, also aus Application.StartupPath & "zeLFClan.zip" mach Application.StartupPath & "\zeLFClan.zip"

beaR schrieb:

'ZIP entpacken
Try
System.IO.Compression.ZipFile.ExtractToDirectory(Application.StartupPath & "zeLFClan.zip", Form3.TextBox3.Text & "\zeLFClan")

Da fehlt eindeutig ein Backslash bei Application.StartupPath & "\zeLFClan.zip"

Was steht denn eigentlich in Form3.TextBox3? (Hier sollten die Controls unbedingt besser benannt werden)

PS: Nutze bitte beim nächsten Mal den Code Tag. Das erleichtert das Lesen.

FunnySunny schrieb:

Die Zeile an sich sieht korrekt aus

Die Zeile sieht rein gar nicht korrekt bzw. sauber aus.
Das StartupPath kannste dir sparen. Wenn die im gleichen Verzeichnis liegt, dann findet er die Datei auch so. Geht vom aktuellen Verzeichnis aus.
Zudem wenn du Pfade zusammenstöpseln musst, würde ich Path.Combine zurückgreifen. Das fügt dir die \ usw. selbst ein.
Zusammen ergibt das dann folgenden Code:

Jetzt kommen wir aber mal zu Form3.TextBox3.Text. Ich lass das jetzt mal stehen, weil das nicht Thema dieses Threads ist. Aber bitte tu dir selbst den Gefallen, nimm folgenden Ratschlag an. Lies dir Dialoge: Instanziierung von Forms und Aufruf von Dialogen durch, wenn du was nicht verstehst, frag nach. Das was du machst fliegt dir früher oder später gewaltig um die Ohren. Ist keine leere Floskel. Lies es wirklich durch.

Was zudem nicht schlecht wäre, wäre ein abfrage ob die Datei existiert,... (-> System.IO.File.Exists usw.). Viele Programme handeln das so, dass falls die Datei nicht da ist wo sie erwartet wurde, man diese manuell suchen und angeben kann und man nicht gleich die ganze Applikation abschießen muss.

Ach ja. Bei solch trivialen Geschichten wie eine Datei wird nicht gefunden lässt sich das Problem innerhalb einer Minute mit Hilfe eines Debuggers lösen. Setzt nen Breakpoint und schau dir die Pfade an. Entweder einfach mit Mouse drüber gehen, vorher in Variabeln speichern oder einer meiner Favoriten, einfach ins "Direktfenster" kopieren und auswerten lassen.
Falls du auch nur in irgend einer Form mit einer Programmiersprache arbeiten möchtest, kommste um debuggen nicht drum rum. Schau dir das auf jeden Fall an. Löst dir so gut wie jedes Problem innerhalb kürzester Zeit. Gibt natürlich viele, viele Anleitungen. Hier mal die erste aus google: codeproject.com/Articles/79508…in-Visual-Studio-A-Beginn Ist für 2010, bei solch Basissachen hat sich jedoch in keiner Version wirklich was geändert. Gibt natürlich noch viel, viel, viel mehr Möglichkeiten (wie z.B. das Direktfenster, das da nicht angesprochen wird). Aber damit kommste schonma recht weit.

In der Textbox befindet sich das Zielverzeichnis, wohin die ZIP kopiert werden soll. Der Backslash hat es leider auch nicht geregelt

Die Abfrage, ob die Datei existiert, kommt kurz davor in einer anderen Form (Form3). Danke jedoch für die Ausführliche Erklärung. In der Textbox findet sich im übrigen das Zielverzeichnis, wohin die ZIP dateien kopiert werden sollen, wie soll ich das sonst regeln? Leider muss ich gestehen, dass der von dir geschriebene Code auch nicht funktioniert :(, warum weiß ich nicht. Kommt genau die gleiche Meldung in der Debug Ausgabe wie vorher. Ich versteh das einfach nicht.

@beaR Wenn du Text an mich richten willst schreibe bitte ein @ und dann meinen Namen in einzelnen Anführungszeichen. Vollzitate verstoßen gegen die Regeln:

§4 Posten von Beiträgen
3. Aufmachung
[...]
f) Das vollständige Zitieren von Beiträgen ("Fullquotes"), die direkt über dem eigenen stehen,
ist völlig unnötig und daher nicht erlaubt. Auch wenn sich dazwischen schon mehrere Beiträge befinden, sollte
man nur das zitieren, was unbedingt erforderlich ist. Gerade sehr große Voll-Zitate schaden der Übersicht enorm.

BTT: @thefiloe s Lösung müsste das Problem beheben.

@radio-ffk Ach so, tut mir Leid. Habe mich gerade erst Angemeldet und wollte mich beeilen, da das Bett langsam ruft. Deswegen habe ich die regeln noch nicht gelesen.

Gut. Ich habe die Lösung auch nicht ausprobiert. Auf diesem Wege wirst du es jedoch garantiert hinbekommen. Aber kannste gleich als gute Übung sehen. Hau den Debugger an, mach das Try-Catch weg (zumindest zum debuggen). Schau wo die Exception fliegt, lies den Message der Exception. Schau dir variabeln durch. Lass wie zuvor gesagt den Pfad über den debugger ausgeben und schau ob es die Datei und das Verzeichnis gibt. Liegt garantiert am 2. Parameter. So viel kann ich sagen. Kann mir zwar denken woran es liegt, aber probier das jetzt wirklich mal zu debuggen. Dann findest den Fehler schnell und haste was gelernt.

@thefiloe Danke für die Hilfe. Ich werde mich morgen mal dran setzen und das ganze mit dem Debugger probieren. Falls ich wirklich nicht weiterkomme, werde ich mich wieder melden. Lieben Gruß

thefiloe schrieb:

mach das Try-Catch weg (zumindest zum debuggen)

Korrigier mich wenn ich falsch liege aber ich halte das für in jedem Falle sinvoll: TryCatch ist ein heißes Eisen

Halte ich für nicht sinnvoll. Try-Catch ist wichtig in jeder Anwendung. Nur muss es halt sinnvoll eingesetzt werden. Bei Dateizugriffen oder auch Netzwerkzugriffen ist das jedoch meistens sinnvoll. Du kannst aus Sicht der Anwendung nicht sagen ob die Datei schon irgendwo geöffnet ist (-> gelocked ist), der Benutzer keine Berechtigung dafür hat usw. Es ist einfach am sinnvollsten an so einer Stelle Try-Catch einzusetzen. Weshalb auf einmal wieder der Hype kommt, nur kein TryCatch... keine Ahnung ist nämlich kompletter Schwachsinn. Nur und das sage ich ganz ehrlich, beim debuggen finde ich es oft angenehmer ohne Try-Catch, da ich dann die Exception nicht erst im Catch-Block bekomme. Als Release-Anwendung ist jedoch 100% sinnvoll hier Try-Catch zu verwenden.

@thefiloe
Danke für die Aufklärung
(Wenn ich ehrlich bin verwende ich ja auch Try Catch )
//Argument Destroyed </ot>

Und Pfade sollte man am besten mit Path.Combine verketten, dann kann so ein Fehler erst gar nicht passieren.

@thefiloe nichts anderes steht in dem verlinkten Thread.

thefiloe schrieb:

Als Release-Anwendung ist jedoch 100% sinnvoll hier Try-Catch zu verwenden.

Aber man muss es richtig machen.
Und hier wirds sicherlich nicht richtig gemacht, denn hier besteht glaub nichtmal ein Konzept, wie's eiglich weitergehen soll, wenn eine Exception auftritt.
Und solange kein Konzept dafür besteht, umgesetzt ist und gründlich getestet (denn Fehler an dieser Stelle sind noch böser) - solange ist TryCatch hinzuschreiben eine Katastrophe.
Und da die Anwendung noch vlt. 6 Monate vonne Release entfernt ist (falls ühaupt eine geplant ist), kann eiglich noch garkein Konzept bestehen, geschweige denn, ein durchgetesteter Code-Zweig für den Fehlerfall.
Und daher hat TryCatch hier nix verloren.
Allenfalls kann man an den fraglichen Stellen in den Code schreiben - damit kommt diese Aufgabe in die Todo-Liste und wird später nicht vergessen.