Hallo Marcus

Meines wissens nach nicht. Man weis aber nach ner Zeit welche Objekte IDisposable implementieren und welche nicht.

Aber noch so als Tipp. Verwende Objekte welche IDisposable implementieren am besten wo es geht in einem Using Block. So kannst du nicht vergessen diese Freizugeben.

Grüße
Sascha

Hi, eine Möglichkeit ist, das NuGet Package nuget.org/packages/Microsoft.CodeAnalysis.FxCopAnalyzers/ zu installieren. Damit bekommst du vom Compiler Warnungen, wenn ein Object IDisposable implementiert und Dispose() nicht aufgerufen wird:


Als Nebeneffekt bekommt man noch eine große Anzahl an anderen Code-Analyse Regeln (alle hier zu finden: docs.microsoft.com/en-us/visua…ode-warnings?view=vs-2019).
Je nach der Code-Qualität kann es dementsprechend passieren, dass der Compiler auf einmal eine große Anzahl an Warnungen ausgibt, aber im Allgemeinen sind diese Regeln meist sinnvoll und sollten auch beachtet werden. (Natürlich kann man Regeln/Warnungen auch case-by-case (de-)aktivieren).

Note: Das Package braucht den Roslyn Compiler um zu funktionieren, also am Besten eine möglichst aktuelle VS Installation.

Richtig, das kann man Projekt für Projekt installieren, je nach Bedarf.
Kleine Info die mir in dem Kontext noch einfällt: Auch wenn man das Package per NuGet installiert, muss man es am Ende nicht mit der App ausliefern, weil es eine Development Dependency ist. Die fertige App hat bei einem Release Build somit keine Abhängigkeit darauf.

Marcus Gräfe schrieb:

Allerdings auch in von VS generiertem Code innerhalb eines DataSets...

Das ist natürlich nicht schön. Liegt wohl daran, dass das Tooling nicht mehr perfekt zusammenpasst. Zum Glück gibt es dafür einen Workaround. Am Beispiel eines neuen Datasets:


1. Finde über die Error List die Warnung im generierten Code und erstelle per Rechtsklick ein SuppressMessage Attribut in der Datei:


2. Das Attribut taucht oben in der Methode auf:


Einfach ausschneiden und für den Moment in der Zwischenablage behalten.

3. Das Dataset aufmachen und F7 drücken. Du solltest in einer Datei landen, die nicht die ganze Zeit neu generiert wird.

4. In dieser Datei das ausgeschnittene Attribut über die Klasse setzen:


Wenn du das für jede Warnung machst, tauchen die Fehler bei neuen Builds nicht mehr auf.

Es gibt auch die Möglichkeit, das ganze mit weniger Aufwand zu schaffen, indem die Warnungen global (also für das ganze Projekt) unterdrückt werden. Der längere Weg oben ist allerdings besser, da die Warnungen natürlich sinnvoll sind. Über den Weg oben werden sie nur im generierten Code unterdrückt und tauchen nach wie vor in anderen, selbst erstellten Dateien, wie gewünscht auf.

@Marcus Gräfe Muss man aber nicht.
Führe ne Codenalyse durch und das Studio sagt Dir, welche Objecte nicht disposed wurden.
Menü Erstellen => Codeanalyse für Lösung ausführen
oder
Menü Erstellen => Codeanalyse für TEILPROJEKT_1 ausführen
oder
Projektmappen-Explorer => Analysieren => Codeanalyse ausführen

Die Codeanalyse ist übrigens sehr zu empfehlen.
Unter Projektmappen-Explorer => Eigenschaften => Codeanalyse kann man noch den Grad einstellen, nicht alle Regeln finden die fehlenden Disposings!
Machst Du Alle Microsoft-Regeln
und dann in der Auswertung => Reliability:

Dazu noch eine Anmerkung: Die "integrierte" Code Analyse ist mittlerweile obsolet und wird auf MSDN beispielsweise als "Legacy Analysis" bezeichnet. Dazu ein paar Links:
docs.microsoft.com/en-us/visua…is-versus-legacy-analysis
docs.microsoft.com/en-us/visua…op-analyzers?view=vs-2019
stackoverflow.com/questions/55…sis-in-visual-studio-2019

Der Weg über die Roslyn Analyzer ist quasi der "way to go". Solange es noch funktioniert (ich zweifle ehrlich gesagt auch daran, dass die Funktion überhaupt irgendwann entfernt wird) kann man die integrierte Analyse von VS natürlich nutzen, aber der Weg über die Roslyn Anaylzer ist mit Blick auf die Zukunft definitiv der bessere, allein schon, weil hier die Entwicklung fortgeführt wird.

Ich empfehle, alle Klassen, die man benutzt sich gründlich im ObjectBrowser anzugucken, was die können. Also die Klasse, und ihre Vererbungs-Hierarchie.
Da stösst man nicht nur auf IDisposable, sondern oft auf ganz viele Möglichkeiten, an die man selbst noch nicht gedacht hat, die einem aber die Arbeit z.t unerhört erleichtern können und den Code verbessern.
ObjectBrowser: ObjectBrowser