Betrachten Sie den folgenden Code:
%Vor% Wenn der Stream writer entsorgt wird, wird intern der FileStream stream freigegeben.
Gibt es dafür ein anderes Design als das MSDN Empfehlung den extern verwendeten Stream in der finally-Klausel zu entsorgen:
%Vor%Dies ist ein Fall, in dem FxCop stark mit Design-Entscheidungen in .NET Framework im Widerspruch steht. Das Problem wird dadurch verursacht, dass der StreamWriter den Besitz des Streams übernimmt. Was im Allgemeinen eine "Fall in the Pit of Success" -Designwahl ist, gehen die meisten Programmierer davon aus, dass es ausreicht, den StreamWriter zu schließen, um den Stream zu entfernen. Besonders wenn sie Close () anstelle von Dispose () verwenden.
Was in den allermeisten Fällen gut funktioniert. In den meisten Fällen ist CryptoStream eine spezielle Verwendung, bei der es sehr problematisch ist. Eine Klasse, die Spülung und nicht diagnostizierbare Fehlfunktionen erfordert, wenn der zugrunde liegende Stream geschlossen wird, bevor der CryptoStream geleert und entsorgt wird. Ein Fall, in dem die FxCop-Warnung angebracht wäre, obwohl es zu kryptisch ist, das spezifische Problem leicht zu erkennen;)
Und der allgemeine Fall, in dem ein Programmierer seine eigene Dispose () -Methode geschrieben und vergessen hat, mehr als einmal sicher zu machen, dass er aufgerufen wird. Auf das sollte die FxCop-Warnung aufmerksam machen, ansonsten ist sie nicht intelligent genug, um zu erkennen, dass eine Dispose-Methode tatsächlich sicher ist.
In diesem speziellen Fall ist die FxCop-Warnung nur nutzlos. Alle von .NET Framework bereitgestellten Dispose () - Methodenimplementierungen sind sicher. FxCop sollte diese Art von Warnungen für .NET Framework-Code automatisch unterdrücken. Aber nicht, Microsoft verwendet es auch. Es gibt eine Menge von [SuppressMessage] -Attributen im .NET Framework-Quellcode.
Die Warnung ist viel zu hässlich und fehleranfällig. Und sinnlos, da eigentlich nichts schief läuft. Denken Sie daran, dass FxCop nur ein Diagnose-Tool ist, das entwickelt wurde, um "Haben Sie diese " Nachrichten zu generieren. Es ist kein Polizist, der dich ins Gefängnis stecken lässt, wenn du die Regeln ignorierst. Das ist die Aufgabe eines Compilers.
Verwenden Sie das Attribut [SuppressMessage], um die Warnung zu deaktivieren.
Die Lösung für diesen speziellen Fall ist, die Überladung des StreamWriter-Konstruktors aufzurufen, mit der Sie es nicht erklären können den zugrunde liegenden Stream zu entfernen .
Leider ist das nur für .Net 4.5; Andernfalls musst du das tun, was du bereits tust.
Siehe auch diesen Thread: Gibt es eine Möglichkeit, einen StreamWriter zu schließen, ohne den BaseStream zu schließen?
Übrigens verursacht der Code im OP NOT eine Ausnahme, wenn ich es versuche!
Im folgenden Beispiel wird davon ausgegangen, dass ein Ordner namens "C: \ TEST" existiert:
%Vor%