Question

In the midst of asking about manually managing CLR memory, I realized I know very little.

I’m aware that the CLR will place a ‘cookie’ on the stack when you exit a managed context, so that the Garbage Collector won’t trample your memory space; however, in everything I’ve read the assumption is that you are calling some library written in C.

I want to an entire write layer of my application in C#, outside of the managed context, to manage data at a low level. Then, I want to access this layer from a managed layer.

In this case, will my Unmanaged C# code compile to IL and be run on the CLR? How does this work?

Answer 1

I assume this is related to the same C# database project you mentioned in the question.

It is technically possible to implement an entire write layers in C/C++ or any other language. And it is technically possible to have everything else in C#. I am currently working on an application that uses unmanaged code for some high-performance low level stuff and C# for business logic and upper level management.

However, the complexity of the task shall not be underestimated. The typical way to do this, is to design a contract that both parties can understand. The contract will be exposed to the managed language and managed language will trigger calls to the native application. If you have ever tried calling a C++ method from C# you will get the idea… Plus every call to unmanaged code has quite significant performance overhead, which may kill the whole idea of low level performance.

If you really interested in high-performance relational databases, then use single low level language.

If you want to have a naive, but fully working implementation of a database, just use C#. Don’t mix these two languages unless you fully understand the complexity. See Raven DB – a document based NoSQL databases that is fully built in C# only.

Will my Unmanaged C# code compile to IL and be run on the CLR?

No, there is no such thing as unmanaged C#. C# code will be always compiled into the IL code and executed by CLR. It is the case of managed code calling unmanaged code. Unmanaged code can be implemented in several languages C/C++/Assembly etc, but CLR will have no idea of what is happening in that code.

Update from a comment. There is a tool (ngen.exe) that can compile C# directly into native architecture specific code. This tool is designed to improve performance of the managed application by removing JIT-compilation stage and putting native code directly into the executable image or library. This code, however, is still “managed” by the CLR host – memory allocation and collection, managed threading, application domains, exception handling, security and all other aspects are still controlled by the CLR. So even though C# can technically be compiled into native code, this code is not running as a standalone native image.

How does this work?

Managed code interoperate with unmanaged code. There are couple of ways to do this:

• Through the code via .Net Interop. This is relatively fast but looks a bit ugly in code (plus it is hard to maintain/test) (good article with C#/C/Assembly samples)
• A much much slower approach, but more open to other languages: web wervices (SOAP, WS, REST and company), queueing (such as MSMQ, NServiceBus and others), also (possibly) interprocess communication. So unmanaged process sits on one end and a managed application sits on the other one.