How much .NET is unmanageable?

Question

Often when I use Reflector, I come across a lot of unsafe codes. Does anyone know how much .NET is unmanaged / safe?

Answer 1

There are many instances of PInvoke that simply call the Win32 API. However, there is some functionality that is implemented in the CLR itself (for example, locking operations). If you want to see how this is done, look at the rotor .

In a detailed explanation of blocking (viewing the source of the rotor) in this blog post.

To answer your question, you need to get all the .NET source code (for example, use NetMassDownloader and grep for a string that says "InternalCall" or "DllImport") and compare this with the number of all lines. Perhaps you could multiply each of these “unmanaged” lines by some factor to guess, or you would have to plunge into the rotor or the Windows source code to get the actual numbers. If you have traveled so far, then everything will become fuzzy (for example, if File.Open calls Win32 CreateFile, should I use CreateFile for .NET? I think not). So, at best, you only multiply "InternalCall" by some factor to guess.

Answer 2

This is a very difficult question to answer. Insecure code is easy to quantify in the sense that it exists in binary code and can be measured using IL instructions.

Real unmanaged code, such as PInvoke or COM, has binary code, but it is negligible. It is the minimum stub required to call the native function. This means that you cannot really measure how much native code is being executed in a managed DLL. All you can do is measure the number of calls that do not give a real estimate of how much unmanaged code is being executed.

Answer 3

Most System.Windows.Forms calls the unmanaged windows API, but I did not find it necessary to manually delete the objects created in this namespace.

When using the System.IO.FileStream class (also calls unmanaged code), make sure you call Dispose when you are done to ensure that the file is closed right there and then, and not when the finalizer is running.

Answer 4

This is not a big deal, since unsafe calls are wrapped with corresponding .NET objects. What you need to worry about is the allocation of resources and the removal of objects that implement IDisposable.