tags:

views:

93

answers:

3

I'm starting to read in-depth on the .NET framework, and its Common Language Runtime. I'm reading a .NET overview by Microsoft and I'm not sure what is meant by this statement.

Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code.

How do you target the Common Language Runtime? I know its defaulted when developing in Visual Studio, but how would you specifically target the CLR?

What code when developing a .NET application wouldn't target the CLR, and thereby be called unmanaged code?

+2  A: 

All code that runs on the .NET framework is managed code. An example of unmanaged code is C++ it's called unmanaged or native code.

DeadMG
So if you develop a C++ application in the .NET framework, its still managed code?
contactmatt
yes, there is something called Managed C++ which generates .NET IL code. Most people avoid it for anything other than interoperability.
Dave Markle
Yes, there is C++/CLI which is managed. But, as far as I'm aware, it's pretty much unused and the overwhelming majority of C++ is compiled as native.
DeadMG
So just to clarify, if you write a visual C++ application, its managed? On MSDN, I found this, "while If you use Microsoft® Visual C++® .NET, you can write managed code using Visual C++, which provides the benefits of a managed execution environment as well as access to powerful capabilities and expressive data types that you are familiar with."
contactmatt
@DeadMG, what exactly does the statement, "compiling to native code" mean? What does "native code" mean in this context?
contactmatt
Native code executes directly on your CPU. Managed code is read by a virtual machine, then compiled to native code, then executed. E.G., JVM/Java, CLI/C#/VB.NET.
DeadMG
+4  A: 

Targetting the runtime means compiling for the runtime, that is, among other things, outputting CIL aka MSIL (as opposed to x86/x64/etc. machine code).

Saying that anything that doesn't target the runtime is "unmanaged code", is a bit of a false dichotomy. Code running on the JVM for example is arguably managed, but I think we can take in this context the sentence to mean "unamanged [by the CLR]".

It would be possible to write a C# compiler that could spit out native code and not target the runtime (albeit you'd probably need some runtime for GC at least), and it is equally possible to write C compiler that spat out CIL. In this example the hypothetical C# compiler wouldn't be targetting the runtime but the hypothetical C compiler would be. The important distinction here is separating the language from its target.

A .NET application that didn't target the runtime would be a contradiction. If it didn't target the runtime it wouldn't be a .NET application.

It can get fuzzier though, with unsafe and P/Invoke. When you use functionality like P/Invoke or COM interop, you end up targeting the runtime and additionally some other stuff. This doesn't mean you've stopped targeting the runtime though, it just means you have additional dependencies beyond the runtime. Keeping track of this sort of stuff is why things like the CLSCompliantAttribute exist.

Logan Capaldo
Is it possible to write an application in Visual Studio that doesn't target the CLR? As far as I know, even writing a visual c++ application targets the CLR.
contactmatt
Sure. The version setting for what version of the CLR to target for C++ projects is sort of an accident of UI, if you don't use `/clr`, that settings doesn't have any effect on the output, and the exe or dll etc. will have no dependency on the CLR.
Logan Capaldo
+2  A: 

It is a fuzzy term, it means "configuring the build tools to generate a binary image that's compatible with the managed runtime". An executable that can run managed code follows the standard PE32 file format. Familiar to you as EXE and DLL files. Such a binary image is called "assembly" in .NET speak. Its format is well documented in this Ecma standard document.

Most build tools in common use are very specific to creating managed assemblies. Like csc.exe and vbc.exe, respectively the C# and VB.NET compilers. Some tools can generate either and must be run with the right command line options to get the desired end result. Like cl.exe and link.exe, the compiler and linker for C/C++ with built-in support for the C++/CLI language. They can also create assemblies that contain a mix of managed IL and machine code.

Especially the latter two tools are not that easy to use to target the managed runtime. It is the job of the IDE and the build system incorporated with Visual Studio to make it easy.

Hans Passant
Wow, nice find on the ECMA Stand document +1
contactmatt