Als Microsoft das .NET Framework vorstellte (standing ovations der COM-geplagten Entwickler auf der PDC 2000) und den Entwicklern (meist mit einer C++-Historie) eine erste Version zur Verfügung stellte, war dies der vielleicht am heißesten diskutierte Punkt in den entsprechenden Foren: Kein Destruktor! Sakrileg!

Tatsächlich war in der ersten Version IDisposable noch gar nicht vorhanden und entstand wohl erst aufgrund des vehementen Feedbacks aus der Entwicklergemeinde. (Microsoft tendiert bei neuen Dingen leider immer zu etwas Betriebsblindheit gegenüber den Nachteilen.)

Danach hat Microsoft aber ziemlich schnell die Kurve bekommen und unterstützt IDisposable et al. inzwischen mit einem eigenen Schlüsselwort in C#, Guidelines, Framework-Klassen und einer ganzen Reihe von FxCop-Rules (CA1001, CA1049, CA1063, CA1816, CA1821, CA2000, CA2004, CA2202, CA2213, CA2215, CA2216, CA2220, CA2221).

Dazu kommt noch eine unüberschaubare Anzahl von Blogbeiträgen.

Und trotzdem bleibt das ein regelmäßig auftretendes Problem, zum Beispiel wenn mal wieder eine Datei nicht sauber geschlossen wird oder ein Objekt Referenzen auf andere Objekte hält, ohne zu berücksichtigen, dass diese disposable sein könnten.

Patrick hat deshalb mit seinem Hinweis völlig recht:

If you are creating and disposing of an object within the context of a single code block, it is basically inexcusable to forget to call Dispose(), because C# provides a using statement that will ensure Dispose() gets called no matter how the code block is exited (whether it be an exception, a return statement, or simply the closing of the block).  

Auch wenn er trotz des C++-Blickwinkels nicht wirklich die verstanden hat, was es mit den diversen Begrifflichkeiten in C, C++ und .NET auf sich hat… (sic!)