Das Objekt...kann mehrere Male in der...verworfen werden
lima-city → Forum → Programmiersprachen → Programmieren mit .NET & Mono
anweisung
beispiel
bug
code
erzeugen
machen
master
meldung
methode
objekt
problem
spezifikation
springen
string
system
teil
url
vermutung
verwendeten ressourcen
warnung
-
Hallo,
ich hoffe dass ich hier jemanden finde, der mir diese Meldung der Codeanalyse erklären kann:
Warnung 5 CA2202 : Microsoft.Usage : Das Objekt "'stream'" kann mehrere Male in der 'Form1.DownloadDMRMasterList(String)'-Methode verworfen werden. Um zu verhindern, dass eine System.ObjectDisposedException generiert wird, sollten Sie die Dispose-Methode nur einmal für ein Objekt aufrufen.:
Der zugehörige Code ist:
Private Sub DownloadDMRMasterList(filename As String) Dim RawList As String, Masters() As String, tmp() As String Dim master As DMR_MASTER Using stream = File.Open(filename, FileMode.Create) Using sw As New StreamWriter(stream) Using Client As New System.Net.WebClient RawList = Client.DownloadString("...") End Using Masters = RawList.Split(New Char() {ChrW(10), " "}) DMR_Masterlist.Clear() 'Liste erzeugen For Each RawList In Masters tmp = RawList.Split("@") If tmp.Length = 3 Then master.IP = tmp(0) master.Name = tmp(1) DMR_Masterlist.Add(master) End If Next 'Werte schreiben sw.WriteLine(DMR_Masterlist.Count) For Each master In DMR_Masterlist sw.WriteLine() sw.WriteLine() sw.WriteLine(master.Name) sw.WriteLine() sw.WriteLine(master.IP) Next End Using End Using End Sub
Ich verstehe nun nicht, warum es da mehrere Wege zum Verwerfen geben soll? Die Lösungen, die man im Internet dazu findet sind immer, man soll using verwenden. Das mache ich ja schon. Was kann ich da noch tun? Selbst wenn ich die Anweisungen noch in eine Try-Catch-Anweisung packe, kommt die Meldung bei der Codeanalyse noch. Dann wäre ja sogar ein raus springen per Exception ausgeschlossen. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Ich habe nicht sehr viel Erfahrung mit .NET (und dort hauptsächlich in C#), aber da es hier immer noch keine Antwort gibt wage ich mal eine Vermutung: Du solltest wahrscheinlich die Using-Direktiven nicht schachteln.
Mach mal eine daraus (statt dreien) und gib alle drei verwendeten Ressourcen Komma-getrennt an.
Der WebClient bliebe dadurch zwar etwas länger in Benutzung als bisher, aber das macht bei den paar Zeilen den Braten nicht fett. -
Ein bisschen Googlen bringt das hier zu Tage: https://msdn.microsoft.com/de-de/library/ms182334.aspx (ist mit C# Beispielen, das ist aber hoffe ich kein Problem)
Kurz: der Stream wird bereits beim End Using des Stream Writers disposed.
Lösung: Entweder den Stream im Konstruktor des StreamWriters initialisieren oder wie in dem Link gezeigt das äußere Using stattdessen mit try - finally lösen.
Beitrag zuletzt geändert: 11.11.2015 21:39:36 von davidlw -
Dann lag ich ja mit meiner Vermutung, dass es an der Schachtelung liegt, nicht ganz falsch...
frage mich aber, warum das so ist?
Der Scope der einzelnen Ressourcen sollte eigntlich völlig klar sein, wieso räumt das Ende des inneren Using den äußeren Stream mit ab? -
Vielen Dank für den Hinweis!
Das mit dem googlen hatte ich schon gemacht. Aber die zitierte Seite kam dabei nocht zum Vorschein. Ich werde das mal versuchen und bescheid geben, ob es was gebracht hat.
Allerdings frage ich mich schon, warum das Verschachteln nicht geht? Das ist ja dann wohl ein Bug im .NET. Wenn alles der Reihe nach abgearbeitet würde, dann könnte ja nix passieren. -
Ich denke, das passiert nur, wenn das Objekt der äußeren using-Anweisung von dem der inneren using-Anweisung verwendet wird. Dabei wird dann sichergestellt, dass alle von dem inneren Objekt verwendeten Ressourcen freigegeben werden. Laut IDisposable Spezifikation muss es an für sich auch möglich sein, dispose mehrfach aufzurufen - man weiß nur nicht, ob sich jeder dran hält. Da es sich hierbei um Framework Teile handelt, gehe ich mal davon aus, dass MS ihre eigenen Spezifikationen befolgt und es kein Problem darstellt. Man könnte die Warnung also auch ignorieren.
Der Teil von .NET ist meiner Meinung nach tatsächlich etwas unschön gelöst, aber damit muss man wohl leben. Als Bug würde ich es hingegen nicht bezeichnen - das Verhalten ist ja durchaus definiert und wenn sich jeder an alle Spezifikationen hält, stellt Dein Code kein Problem dar. -
Hat keine Änderung gebracht. Jetzt wird die Fehlermeldung halt in der Finally-Anweisung raus geworfen.
-
Hast Du auch an das „stream = null“ gedacht? (siehe Code Beispiel auf der verlinkten Seite)
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
