2009-03-04 7 views
4

Wenn ich den Reflektor verwende, stolpere ich häufig über viel unsicheren Code. Wer weiß, wie viel von .NET nicht verwaltet/sicher ist?Wie viel von .NET ist nicht verwaltet?

+0

Welchen Teil von .NET sprechen Sie genau? Sofern Sie nicht selbst Code als unsicher angeben, ist Ihr Code nicht unsicher. –

+0

Wie wäre das beantwortbar? Möchten Sie Messungen in Codezeilen oder etwas? –

+0

So ziemlich jeder Teil wie in der Liste, Array-Klasse aussehen. –

Antwort

0

Es ist nicht wirklich wichtig, da die unsicheren Aufrufe von den entsprechenden .NET-Objekten umschlossen sind. Worüber Sie sich Sorgen machen müssen, ist die Ressourcenzuweisung und das Entsorgen von Objekten, die IDisposable implementieren.

6

Es gibt viele Instanzen von PInvoke, die nur Win32-APIs aufrufen. Es gibt jedoch einige Funktionen, die in der CLR selbst implementiert sind (z. B. Interlock-Operationen). Wenn Sie sehen möchten, wie das gemacht wird, schauen Sie sich Rotor an.

Ich gehe auf meinem Blog in eine detaillierte Erklärung der Verriegelung (Anzeigen der Rotor-Quelle) in this post.

Um Ihre Frage speziell zu beantworten, müssten Sie den gesamten .NET-Quellcode erhalten (z. B. NetMassDownloader und grep für Zeilen mit der Bezeichnung "InternalCall" oder "DllImport") und diese mit der Anzahl aller Zeilen vergleichen. Vielleicht könnten Sie jede dieser "unmanaged" Zeilen um einen Faktor multiplizieren, um zu raten, oder Sie müssten in Rotor oder den Windows-Quellcode tauchen, um die tatsächlichen Zahlen zu erhalten. Wenn Sie so weit gegangen sind, dann werden die Dinge unscharf (z.B. wenn File.Open Win32s CreateFile aufruft, sollte CreateFile dann zu .NET gezählt werden? Ich denke nicht). Also, im besten Fall multipliziert man nur die "InternalCalls" mit einem gewissen Faktor.

+0

NetMD ist ziemlich interessant. –

1

Ein Großteil von System.Windows.Forms ruft die API für nicht verwaltete Windows auf, aber ich habe nicht die Notwendigkeit gefunden, Objekte, die ich in diesem Namespace erstellt habe, manuell zu entfernen.

Wenn Sie die System.IO.FileStream-Klasse verwenden (auch in nicht verwaltetem Code), sollten Sie unbedingt Dispose aufrufen, damit Sie sicherstellen können, dass die Datei genau dort und nicht beim Ausführen des Finalizers geschlossen wird.

+0

Es gibt einen Grund, dass ein Objekt IDisposable implementiert. Möglicherweise sehen Sie kein Problem, aber Sie haben wahrscheinlich einen Speicherverlust, wenn Sie die Objekte nicht entsorgen. –

6

Dies ist eine wirklich schwierige Frage zu beantworten. Unsicherer Code ist in dem Sinne einfach zu quantifizieren, dass er in der Binärdatei existiert und in Form von IL-Anweisungen gemessen werden kann.

Wirksamer nicht verwalteter Code, sagen wir PInvoke oder COM, haben Code in der Binärdatei, aber er ist unbedeutend. Sie stellt nur den minimalen Stub dar, der zum Aufrufen der nativen Funktion erforderlich ist. Dies bedeutet, dass Sie nicht wirklich messen können, wie viel systemeigener Code in einer verwalteten DLL ausgeführt wird. Alles, was Sie tun können, ist die Anzahl der Aufrufe zu messen, die kein echtes Maß dafür liefert, wie viel nicht gemanagter Code ausgeführt wird.

Verwandte Themen