Verwendete DLL unloaden oder freistellen zum löschen

  • VB.NET

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von Kangaroo.

    Verwendete DLL unloaden oder freistellen zum löschen

    Guten Tag Zusammen,

    In meinem Programm wird mithilfe zweier DLL's (von WinRAR), eine RAR Datei entpackt. Hierfür wird benötigt: "unrar.dll" sowie "UnRARNET.dll".
    Die "UnRARNET.dll" habe ich in den Verweisen importiert. Die "unrar.dll" kann nicht importiert werden, jedoch wird sie trotzdem zum entpacken benötigt.

    Deshalb werden vor dem Entpackungsvorgang, beide DLL's aus den Ressourcen, in den aktuellen EXE Pfad kopiert. In der Form wird noch Imports RARNET importiert.

    VB.NET-Quellcode

    1. Dim Res() As Byte = My.Resources.unrar
    2. Dim Res2() As Byte = My.Resources.UnRARNET
    3. Dim fsRes As FileStream = File.Create(Application.StartupPath & "\unrar.dll")
    4. Dim fsRes2 As FileStream = File.Create(Application.StartupPath & "\UnRARNET.dll")
    6. fsRes.Write(Res, 0, Res.Length)
    7. fsRes.Close()
    8. fsRes2.Write(Res2, 0, Res2.Length)
    9. fsRes2.Close()

    Dann wird der Entpackungsvorgang in einem eigenen Thread gestartet.

    Problem: Nun würde ich gerne nach dem Entpackungsvorgang die DLL's wieder löschen, da diese ja nicht mehr benötigt werden. NUR sind diese sobald der Entpackungsvorgang gestartet wurde, so lange gesperrt, bis das Programm komplett beendet wurde. (gehe ich zumindest davon aus)

    Mitlerweile hab ich versucht mit System.IO.File.Delete(PathUnRARNET), My.Computer.FileSystem.DeleteFile(PathUnRARNET) und per

    VB.NET-Quellcode

    1. Dim Prozess As New Process
    2. Prozess.StartInfo.WindowStyle = ProcessWindowStyle.Normal
    3. Prozess.StartInfo.FileName = "CMD"
    4. Prozess.StartInfo.Arguments = ("/k del /F /Q """ & PathUnRARNET & """")
    5. Prozess.Start()

    die DLL's zu löschen, was allerdings immer gescheitert ist, da die DLL's nach dem Entpackungsvorgang weiterhin gesperrt sind.

    Gibt es eine Möglichkeit die DLL's wieder freizugeben oder über einen anderen Weg zu löschen?

    MfG, FireEmerald

    Die "UnRarNet.dll" ist ein .NET-Wrapper für die "unrar.dll".
    Wenn Du also die "UnRarNet.dll" entladen hast, hast Du automatisch die "unrar.dll" entladen.
    Wenn Du in Deinem Programm die Instanz einer speziellen Klasse erstellst, die die "UnRarNet.dll" benötigt, könnte es sein (ich bin mir nicht sicher), dass nach dem Zerstören dieser Instanz die DLLs gelöscht werden können.
    Probiere dies mal aus.
    Allerdings:
    Warum machst Du solch Aufwand, die DLLs in die Ressourcen reinzupacken, um sie zur Verwendung zu extrahieren? Packe sie gleich neben die Exe und fertig.
    Oder
    Extrahiere sie ein Mal und sieh beim 2. Mal nach, ob sie schon da ist.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    FireEmerald schrieb:

    In meinem Programm wird mithilfe zweier DLL's (von WinRAR), eine RAR Datei entpackt. Hierfür wird benötigt: "unrar.dll" sowie "UnRARNET.dll".
    Gibt es einen zwingenden Grund für das RAR Format ?

    Anscheinend ist die ChilKat Library ja nur ein Wrapper um die Original WinRar Library und damit immer auf diese angewiesen. Besser wäre in diesem Fall eine reine .NET Library wie zum Beispiel DotNetZip. Diese könnte dann auch aus dem Ressourcen importiert werden (AssemblyResolve Event).

    FireEmerald schrieb:

    Gibt es eine Möglichkeit die DLL's wieder freizugeben oder über einen anderen Weg zu löschen?
    Nach meinem Verständnis kannst Du eine DLL nicht wieder entladen, sondern nur die ganze AppDomain droppen. Insofern müsste UnRarNet in eine separate AppDomain geladen werden.

    Was genua und wieviele Dateien sollen denn entpackt werden ? Sofern es nur eine (oder wenige) Ressourcen sind wäre eine mit GZip gepackte eingebundene Ressource am elegantesten, da diese über einen normalen ZipStream wieder dekomprimiert werden kann.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Kangaroo“ ()

    RodFromGermany schrieb:

    Warum machst Du solch Aufwand, die DLLs in die Ressourcen reinzupacken, um sie zur Verwendung zu extrahieren? Packe sie gleich neben die Exe und fertig.
    Das ist nicht wirklich ein "Aufwand". Zumindest empfinde ich dies nicht als solchen. Eher als ein Vorteil, weil dann der User wo das Programm herunterlädt nur eine Exe hat und keine Rar oder Zip Datei.

    Kangaroo schrieb:

    Gibt es einen zwingenden Grund für das RAR Format ?
    Ja, diesen gibt es. Dieser muss jedoch nicht weiter erläutert werden. Fakt ist es muss eine Rar Datei sein.

    Kangaroo schrieb:

    Was genau und wieviele Dateien sollen denn entpackt werden ? Sofern es nur eine (oder wenige) Ressourcen sind wäre eine mit GZip gepackte eingebundene Ressource am elegantesten, da diese über einen normalen ZipStream wieder dekomprimiert werden kann.
    Es sollen mehere Gigabyte an Dateien entpackt werden. Alles in einer Rar Datei gepackt. Dies lässt sich nicht ändern.


    Kangaroo schrieb:

    Nach meinem Verständnis kannst Du eine DLL nicht wieder entladen, sondern nur die ganze AppDomain droppen. Insofern müsste UnRarNet in eine separate AppDomain geladen werden.

    Das hört sich recht komplex und kompliziert an, ist es dies auch oder hält sich der Aufwand in Grenzen? :whistling:

Facebook
Telefonspende