Сколько из .NET неуправляем?

Question

Часто, когда я использую Reflector, я сталкиваюсь с большим количеством небезопасного кода. Кто-нибудь знает, сколько из .NET неуправляемо / безопасно?

Answer 1

Это действительно сложный вопрос. Небезопасный код легко определить количественно в том смысле, что он существует в двоичном коде и может быть измерен в терминах инструкций IL.

Реальный неуправляемый код, скажем, PInvoke или COM, имеет код в двоичном коде, но он незначителен. Он представляет собой только минимальную заглушку, необходимую для вызова нативной функции. Это означает, что вы не можете реально измерить, какой объем нативного кода используется в управляемой DLL. Все, что вы можете сделать, это измерить количество вызовов, которое не дает реальной оценки объема неуправляемого кода.

Answer 2

Есть много экземпляров PInvoke, которые просто вызывают Win32 API. Тем не менее, есть некоторые функциональные возможности, которые реализованы в самом CLR (например, операции с блокировкой). Если вы хотите увидеть, как это делается, посмотрите на Ротор .

Я вхожу в подробное объяснение блокировки (просмотр источника Rotor) в этой записи в моем блоге.

Чтобы конкретно ответить на ваш вопрос, вам нужно получить весь исходный код .NET (например, использовать NetMassDownloader и grep для строк, которые говорят "InternalCall" или "DllImport") и сравнить его с количество всех строк Возможно, вы могли бы умножить каждую из этих «неуправляемых» строк на какой-то фактор, чтобы угадать, или вам пришлось бы погрузиться в Rotor или исходный код Windows, чтобы получить реальные цифры. Если вы зашли так далеко, то все станет нечетко (например, если File.Open вызовет Win32 CreateFile, тогда следует ли CreateFile считать в .NET? Я думаю, что нет). Таким образом, в лучшем случае вы бы умножили «InternalCall» на некоторый коэффициент, чтобы угадать.

Answer 3

Большая часть System.Windows.Forms обращается к неуправляемому API Windows, но я не нашел необходимости вручную удалять объекты, которые я создаю в этом пространстве имен.

При использовании класса System.IO.FileStream (также обращающегося к неуправляемому коду), убедитесь, что вы вызываете Dispose, когда закончите, чтобы гарантировать, что файл будет закрыт сразу же, а не тогда, когда выполняется финализатор.

Answer 4

Это не имеет значения, поскольку небезопасные вызовы обертываются соответствующими объектами .NET Что вас должно беспокоить, так это распределение ресурсов и удаление объектов, реализующих IDisposable.