How can I distinguish between managed & unmanaged code in C#

Question

As per MSDN,

Managed Code - Code that could be understood and managed by CLR

Unmanaged Code - Code that could not handled by CLR

But I am wondering how do I identify which resource or class is CLR compliant & which Not.

I referred below links

C# Managed Unmanaged code

How do we distinguish between managed and unmanaged resources in C#? Is TextFieldParser unmanaged?

public class Customer 
{
   //What makes this CLR compliant
}


public class DbConnectionHandler: IDisposable
{
 //Database Connection & other related stuff

 //What makes this CLR Non-Compliant
}

If I am using EF (LINQ to Entities), it is translated to native SQL. SO all LINQ falls under Unmanaged Code category?

Thanks!

C# is a managed language. However a managed class can of course **use** unmanaged resources, e.g. a database-connection, which you should dispose when ready. — MakePeaceGreatAgain, Feb 22 '19 at 08:42
@mjwills hahaha, not idle curiosity but was asked this in a recent interview — Kgn-web, Feb 22 '19 at 08:49
@mjwills, I gave definitions & gave an example of DbConnection & so. Added that in old days, there were COM components. They fall under UnManaged Code — Kgn-web, Feb 22 '19 at 08:53
@mjwills, makes sense. but to get clarity. If somebody had asked you " What is Managed & UnManaged Code" What makes DbConnection Opening & Closing Unmanaged Code" What would have you answerd ? — Kgn-web, Feb 22 '19 at 08:58
Marc's answer is a good one. I personally would pitch a bit higher level, but whether that is what the interviewer wants or not - I don't know. I'd say managed code and resources generally relates to code written to run on the CLR and which is managed by the runtime. Unmanaged means it 'can't be seen' by the runtime, and thus can't be managed as well (think PInvoke or COM). `What makes DbConnection Opening & Closing Unmanaged Code` That is a silly interview question. It is too abstract. A better one would be 'why do you need to dispose of the connection'. That gets to the heart of the matter. — mjwills, Feb 22 '19 at 09:02
@Kgn-web you could write a `DbConnection` using purely managed code... as long as you're happy to rewrite all the database comms code in C#; assuming that we're talking about an out-of-process database server, then at some point you'd need to use an unmanaged resource such as a socket, but *your `DbConnection`* code would only talk to the managed `Socket` layer, so your connection would be entirely managed — Marc Gravell, Feb 22 '19 at 09:18

score 5 · Answer 1 · answered Feb 22 '19 at 08:43

"unmanaged" here is referring to in-process execution of non-CLR code (don't confuse that with "CLR compliant", whatever that might mean); so - EF and LINQ are managed (or mostly managed), but they often talk indirectly to unmanaged dlls (think: C/C++ dlls, etc - nothing to do with the CLR) at some point - for example, many of the ADO.NET providers are really P/Invoke layers to an unmanaged database drivers - or unsafe code that talks to manually allocated raw memory in the local process (a chunk of memory allocated via Marshal.AllocHGlobal, for example). Usually these exist in a dual state: there's a managed layer that abstracts and hides the unmanaged layer - so application level code rarely talks to unmanaged code directly.

The fact that native SQL is involved is unrelated, as that isn't "managed" or "unmanaged" - it isn't in-process, so it is a different category altogether.

How can I distinguish between managed & unmanaged code in C#

1 Answers1