Develop Reference

How compiler knows whether the running code is Managed or UnManaged in .NET framework

When reading about the basics of .NET like Managed and Unmanaged code, the code which runs under CLR and developed in .NET framework is managed while unmanaged does not run under CLR and developed outside the .NET framework. Moreover, thinking and knowing about the practicalities about the codes and how they run and how the compiler knows the type of code was a bit confusing. So, to get rid of this confusion, felt to ask this on here.
Please let me know about this.
Thanks in advance!! :)

If you're talking about the compilers for languages such as C#, VB(.NET) etc, then: from the compiler's perspective they are always managed. Everything they output is managed code, i.e. IL. There are places where C# etc get close to directly unmanaged - for example:
when using unsafe code and "unmanaged pointers", C# can talk directly to unmanaged memory - but it always expresses how to do that via IL (IL contains operators for dealing with raw pointers)
P/Invoke layers can express boundaries for talking to external unmanaged code
However, in both cases it is the JIT compiler at runtime (or the AOT compiler if using a non-JIT target platform) that interprets these unmanaged intents expressed in IL, and outputs the CPU intrinsics to implement them. But... that's exactly what the JIT / AOT does for all IL, so ... nothing different there.
So: from the perspective of a compiler for a language such as C# / VB(.NET), there is no actual question here: it is always working 100% managed in terms of the output - and since the compilers are (since Roslyn) also .NET code, they are 100% managed in terms of their actual execution too.
If you meant something different, it would be worth clarifying the question, being really, really specific about what scenario(s) you have in mind, preferably with examples.

2 basic but interesting questions about .NET

when I first saw C#, I thought this must be some joke. I was starting with programming in C. But in C# you could just drag and drop objects, and just write event code to them. It was so simple.
Now, I still like C the most, because I am very attracted to the basic low level operations, and C is just next level of assembler, with few basic routines, so I like it very much. Even more because I write little apps for micro-controllers.
But yesterday I wrote very simple control program for my micro-controller based LED cube in asm, and I needed some way to simply create animation sequences to the Cube. So, I remembered C#. I have practically NO C# skills, but still I created simple program to make animation sequences in about hour with GUI, just with help of google and help of the embedded function descriptions in C#.
So, to get to the point, is there some other reason then top speed, to use any other language than C#? I mean, it is so effective. I know that Java is a bit of similar, but I expect C# to be more Windows effective since its directly from Microsoft.
The second question is, what is the advantage of compiling into CIL, and than run by CLR, than directly compile it into machine code? I know that portability is one, but since C# is mainly for Windows, wouldn´t it be more powerful to just compile it directly? Thanks.

1 - diff languages have their pros and cons. There are families of languages (functional, dynamic, static, etc.) which are better for specific problem domains. You'd need to learn one in each family to know when to choose which one. e.g. to write a simple script, I'd pick Ruby over C#
2 - Compiling it to CIL: Portability may not be a big deal.. but to be precise Mono has an implementation of the CLR on Linux. So there. Also CIL helps you to mix-and-match across languages that run on the CLR. e.g. IronRuby can access standard framework libraries written in C#. It also enables the CLR to leverage the actual hardware (e.g. turn on optimizations, use specific instructions) on which the program is run. The CLR on 2 machines would produce the best native code from the same IL for the respective machine.

Language and platform choice are a function of project goal. It sounds like you enjoy system level programming, which is one of the strong points of using C/C++. So, keep writing systems level code if that's what you enjoy.
Writing in C# is strong in rapid business application development where the goals are inherently different. Writing good working code faster is worth money in both man-hours and time to market. Microsoft does us a huge favor with providing an expressive language and a solid framework of functionality that prevents us from having to write low level code or tooling for 95% of business needs.

One important advantage of IL is language independance. You can define modules in project which should be done in C++, some in C# and some in VB.net. All these projects when compiled give respective assemblies(.dll/.exe). This you can use the assembly for C++ project in the c# one and vice versa. This is possible because.. no matter which language (.net supported) you choose.. all compile to the same IL code.

I'm not sure that C# is more effective only because is a Microsoft product. If you use the Visual Studio, or other RAD, some of the code is auto-generated and sometimes is less efficient. Some years ago I was a dogmatic, thinking only C can response all our prayers :-P , but now I think virtual machines can help a lot in the way to optimize code before to execute it (like a RDBMS), storing in caché pieces of code to execute later, etc. Including the possibility to create "clusters" of virtual machines as Terracotta does. At least the benefits of having an extra abstraction layer are bigger that don't have it.

I agree with spoulson. C# is really good at solving business problems. You can very effective create a framework that models your business processes and solve many of those problems with object orientation and design patterns. In that respect it provides much of the nice object oriented capability that C++ has.
If you are concerned with speed, C is the route to go for the reasons that you stated.

Further on the second question: you can run NGEN to generate a native image of the assembly, which can improve performance. Not quite machine code, but since it bypasses the JIT (just-in-time compile) phase, the app will tend to run much faster.
http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead of using the
just-in-time (JIT) compiler to compile
the original assembly.

"is there some other reason then top
speed, to use any other language than
C#?"
I can think of at least four, all somewhat related:
I have a a large current investment in 'language X', and I don't have the time or money to switch to something else. (Port an existing code base, buy/acquire/port libraries, re-develop team skills in C#, learn different tools.)
An anticipated need to port the code to a platform where C# is not supported.
I need to use tools that are not available in C#, or are not as well supported. (IDE's, alternate compilers, code generators, libraries, the list goes on and on...)
I've found a language that's even more productive. ;-)
"what is the advantage of compiling
into CIL, and than run by CLR, than
directly compile it into machine
code?"
It's all about giving the runtime environment more control over the way the code executes. If you compile to machien code, a lot becomes 'set in stone' at that time. Deferring compilation to machine code until you know more about the runtime environment lets you optimize in ways you might not be able to otherwise. Just a few off the top of my head:
Deferring compilation lets you select instructions that more closely match your host CPU. (To use 64-bit native instructions when you have them, or the latest SSE extensions.)
Deferring code lets you optimize in ways you might not be able to otherwise. (If you have only one class at runtime that's derived from a specific interface, you can start to inline even virtual methods, etc.)
Garbage collectors sometimes need to insert checkpoints into user code. Deferring compilation lets the GC have more control and flexibility over how that's done.

First answer: C# should be used by default for new projects. There are a few cases where it hasn't caught up yet to C++ (in terms of multi-paradign support), but it is heading in that direction.
Second answer: "portability" also includes x86 / x64 portability, which can be achieved by setting the platform to AnyCPU. Another (more theoretical at this point) advantage is that the JIT compiler can take advantage of the CPU-specific instruction set and thus optimize more effectively.

What is managed or unmanaged code in programming?

I am using a specific command in in my C# code, which works well. However, it is said to misbehave in "unmanaged" code.
What is managed or unmanaged code?

This is a good article about the subject.
To summarize,
Managed code is not compiled to machine code but to an intermediate language which is interpreted and executed by some service on a machine and is therefore operating within a (hopefully!) secure framework which handles dangerous things like memory and threads for you. In modern usage this frequently means .NET but does not have to.
An application program that is executed within a runtime engine
installed in the same machine. The application cannot run without it.
The runtime environment provides the general library of software
routines that the program uses and typically performs memory
management. It may also provide just-in-time (JIT) conversion from
source code to executable code or from an intermediate language to
executable code. Java, Visual Basic and .NET's Common Language Runtime
(CLR) are examples of runtime engines. (Read more)
Unmanaged code is compiled to machine code and therefore executed by the OS directly. It therefore has the ability to do damaging/powerful things Managed code does not. This is how everything used to work, so typically it's associated with old stuff like .dlls.
An executable program that runs by itself. Launched from the operating
system, the program calls upon and uses the software routines in the
operating system, but does not require another software system to be
used. Assembly language programs that have been assembled into machine
language and C/C++ programs compiled into machine language for a
particular platform are examples of unmanaged code.(Read more)
Native code is often synonymous with Unmanaged, but is not identical.

Here is some text from MSDN about unmanaged code.
Some library code needs to call into unmanaged code (for example, native code APIs, such as Win32). Because this means going outside the security perimeter for managed code, due caution is required.
Here is some other complimentary explication about Managed code:
Code that is executed by the CLR.
Code that targets the common language runtime, the foundation of the .NET Framework, is known as managed code.
Managed code supplies the metadata necessary for the CLR to provide services such as memory management, cross-language integration, code access security, and automatic lifetime control of objects. All code based on IL executes as managed code.
Code that executes under the CLI execution environment.
For your problem:
I think it's because NUnit execute your code for UnitTesting and might have some part of it that is unmanaged. But I am not sure about it, so do not take this for gold. I am sure someone will be able to give you more information about it. Hope it helps!

When you think of unmanaged, think machine-specific, machine-level code. Like x86 assembly language. Unmanaged (native) code is compiled and linked to run directly on the processor it was designed for, excluding all the OS stuff for the moment. It's not portable, but it is fast. Very simple, stripped down code.
Managed code is everything from Java to old Interpretive BASIC, or anything that runs under .NET. Managed code typically is compiled to an intermediate level P-Code or byte code set of instructions. These are not machine-specific instructions, although they look similar to assembly language. Managed code insulates the program from the machine it's running on, and creates a secure boundary in which all memory is allocated indirectly, and generally speaking, you don't have direct access to machine resources like ports, memory address space, the stack, etc. The idea is to run in a more secure environment.
To convert from a managed variable, say, to an unmanaged one, you have to get to the actual object itself. It's probably wrapped or boxed in some additional packaging. UNmanaged variables (like an 'int', say) - on a 32 bit machine - takes exactly 4 bytes. There is no overhead or additional packaging. The process of going from managed to unmanaged code - and back again - is called "marshaling". It allows your programs to cross the boundary.

In as few words as possible:
managed code = .NET programs
unmanaged code = "normal" programs

Managed code is what C#.Net, VB.Net, F#.Net etc compilers create. It runs on the CLR, which among other things offers services like garbage collection, and reference checking, and much more. So think of it as, my code is managed by the CLR.
On the other hand, unmanaged code compiles straight to machine code. It doesn't manage by CLR.

Basically unmanaged code is code which does not run under the .NET CLR (aka not VB.NET, C#, etc.). My guess is that NUnit has a runner/wrapper which is not .NET code (aka C++).

Managed Code: code written in .NET language like C#, VB.NET.
UnManaged Code: code not written in .NET language and MSIL does
not understand what it is and can not run under CLR; like third-party controls we used in our .NET applications which is not created in .NET languages.

Managed Code:
Code that runs under a "contract of cooperation" with
the common language runtime. Managed code must supply the metadata
necessary for the runtime to provide services such as memory
management, cross-language integration, code access security, and
automatic lifetime control of objects. All code based on Microsoft
intermediate language (MSIL) executes as managed code.
Un-Managed Code:
Code that is created without regard for the
conventions and requirements of the common language runtime. Unmanaged
code executes in the common language runtime environment with minimal
services (for example, no garbage collection, limited debugging, and
so on).
Reference: http://www.dotnetspider.com/forum/11612-difference-between-managed-and-unmanaged-code.aspx

NUnit loads the unit tests in a seperate AppDomain, and I assume the entry point is not being called (probably not needed), hence the entry assembly is null.

Managed code runs inside the environment of CLR i.e. .NET runtime.In short all IL are managed
code.But if you are using some third party software example VB6 or VC++ component they are
unmanaged code as .NET runtime (CLR) does not have control over the source code execution
of the language.

Managed Code :- Code which MSIL (intermediate language) form is developed after the language compiler compilation and directly executed by CLR called managed code.
eg:- All 61 language code supported by .net framework
Unmanaged Code:- code that developed before .net for which MSIL form is not available and it is executed by CLR directly rather CLR will redirect to operating system this is known as unmanaged code.
eg:-COM,Win32 APIs

First of all understand this, before .NET framework, Microsoft were providing the stand-alone products like MFC (Visual C++), VB, FoxPro etc.
In 2002, Microsoft combined its products and made .NET framework. Now there is a difference between how code was executed before and how code is managed and executed in .NET framework. Microsoft introduced concept of CLR with .NET framework which compiles the code coming from any supported lanugague of .NET framework and provide additional functionalities like memory mangement, garbage collection etc. But, such CLR features weren't available directly before.
So if you are creating library/code in .NET framework (compiled with
CLR) then that is called Managed code. You can use this library
further in other .NET application/project, and there too, CLR will
understand how it was compiled before, and that's why it remains your
manage code.
OTOH if you want to use the libraries that were written prior to .NET framework then you can do with certain limitations, but remember, since CLR wasn't there at that time, so now, CLR won't understand and compile this code again. And this will be called unmanaged code. Please note that, libraries/assembilies created by some third party to provide certain features/tool may also be considered as unmanage code if is not CLR compatiblie.
In laymen terms, Manage code is something which your CLR understands and can compile it on its own for further execution. In .NET framework, (from any language thats work on .NET framework) When code goes to CLR then code supply some meta data information, so that CLR can provide you features specified here. Few of them are Garbage collection, Performance improvements, cross-language integration, memory management etc.
OTOH, unmanged code is something specific to machine and ready to use, no need to process it further.

From Pro C# 5 and the .NET 4.5 Framework:
Managed vs. Unmanaged Code:
Perhaps the most important point to understand about the C# language is that it can produce code that
can execute only within the .NET runtime (you could never use C# to build a native COM server or an
unmanaged C/C++ application). Officially speaking, the term used to describe the code targeting the
.NET runtime is managed code. The binary unit that contains the managed code is termed an assembly
(more details on assemblies in just a bit). Conversely, code that cannot be directly hosted by the .NET
runtime is termed unmanaged code.

Is there any work being done to create a C# compiler to produce native exe's?

Is there any work being done to create a C# compiler to produce native exe's? e.g. the output is a native exe and NOT a .NET assembly.

Why don't you try NGen. For exemple Paint.NET use nGen to create native images after installation.

If you want a standalone deployment (i.e. without needing the framework), there are a few options - see here. However, I'm not aware of anything that will reliably produce purely unmanaged code. What is the use-case you have in mind? For embedded etc there is micro-framework, CF, etc.

There is such solution for Mono, this is 'mkbundle' - static linking instead of using JIT/CLR/GAC, I guess

You'd still have to provide the libraries in some form so either you'd still have to have a runtime installed, or the native exe would have to be huge.

There are two active projects. They are geared toward CIL-based operating systems, but the current iteration of MOSA Compiler Framework runs on Windows (unit tests etc.) and has limited boot support. Cosmos used to have a Windows architecture and a few plugs, but they don't do Windows any more - only booting into a CIL environment.
Cosmos is much futher along however, they have pretty much nailed object support. MOSA is only bare-metal (static methods) for now - although it is done the 'proper' way and well unit-tested (and I think making faster progress). Give it a few more months and then go back and have a look.
Niether has a JIT at the moment (which doesn't matter since you don't want one). It is all compiled to machine code ahead of time.
MOSA (Compiler Framework)
COSMOS (IL2CPU)

.NET linker
You might find this interesting to read as well: .NET Internals and Native Compiling.
Note that for the reflection to work a lot of information about the code will always have to present.

What exactly is "managed" code?

I've been writing C / C++ code for almost twenty years, and I know Perl, Python, PHP, and some Java as well, and I'm teaching myself JavaScript. But I've never done any .NET, VB, or C# stuff. What exactly does managed code mean?
Wikipedia describes it simply as
Code that executes under the management of a virtual machine
and it specifically says that Java is (usually) managed code, so
why does the term only seem to apply to C# / .NET?
Can you compile C# into a .exe that contains the VM as well, or do you have to package it up and give it to another .exe (a la java)?
In a similar vein,
is .NET a language or a framework, and what exactly does "framework" mean here?
OK, so that's more than one question, but for someone who's been in the industry as long as I have, I'm feeling rather N00B-ish right now...

When you compile C# code to a .exe, it is compiled to Common Intermediate Language(CIL) bytecode. Whenever you run a CIL executable it is executed on Microsofts Common Language Runtime(CLR) virtual machine. So no, it is not possible to include the VM withing your .NET executable file. You must have the .NET runtime installed on any client machines where your program will be running.
To answer your second question, .NET is a framework, in that it is a set of libraries, compilers and VM that is not language specific. So you can code on the .NET framework in C#, VB, C++ and any other languages which have a .NET compiler.
https://bitbucket.org/brianritchie/wiki/wiki/.NET%20Languages
The above page has a listing of languages which have .NET versions, as well as links to their pages.

I don't think you are alone in being confused about what .Net is. There are already other answers that should have you covered but I'll throw out this tidbit of info for others.
To see what .Net "really" is simply go to c:\Windows\Microsoft.Net\Framework
In there you'll see folders that are specfic to the version(s) you have installed. Go into the v2.0.xxxxx folder if you have it installed for example.
In that folder is the framework. You will basically see a bunch of .exe files and .dll files. All the DLL files that start with System.*.dll is essentially the .Net framework.
The .exe files you'll see in that folder are utilities for developers as well as compilers. You mentioned C#. Find the csc.exe file. That's your C# compiler.
Building a program is really simple. Throw the following code into a hello.cs file.
using System;
class Program
{
static void Main(string[] args)
{
Console.WriteLine("hello world");
}
}
Then on the command line type> csc hello.cs
That will generate you a .exe file. Run it and it will spit out 'hello world' obviously.
The line that says Console.WriteLine() is calling into the Framework. Console is an object that lives within the System namespace and WriteLine() is a static method.
This is the disassembled code for that Console.WriteLine() method:
[HostProtection(SecurityAction.LinkDemand, UI=true)]
public static void WriteLine(string value)
{
Out.WriteLine(value);
}
When people say things like, "Should I use PHP or .Net?", or "Should I use Python or .Net" you start to see how that's the wrong thing to be discussing. They are obviously comparing a language to a Framework. C# is a language and it is just one of the many languages that can be used to write code on top of the .Net platform. That same method of Console.WriteLine() can be invoked from C#, VB.Net, Pascal, C++, Ruby, Python, F# and any other language that has been made to work on top of the .Net platform.
I hope that helps.
-Keith

Mostly its referring to the fact that all of your memory allocations are "managed" for you. If you are using managed code you don't have to worry about freeing your objects when you are done with them. Simply allowing them to go out of scope will mean that the VM will eventually recognize that there are no longer any references to them and will Garbage collect them returning the memory to the system.
Unmanaged code on the other hand will simply "leak" unless you explicitly free your pointers before you discard the references.

It's primarily used to describe .NET because that's the term Microsoft chose to differentiate .NET from C/C++ and other older languages. Microsoft chose it because it wasn't a term that was usually associated with Java because they didn't want to emphasize the similarities between C#/.NET and Java (as opposed to calling it something like 'virtual machine code' which would make it sound much more Java like). Basically, the use of "managed code" is marketing driven, rather than technically driven, terminology.

Under .NET and Visual C++ specifically, you can have both Unmanaged and Managed code. The terms refer to the manner in which memory is allocated and 'managed'.
Unmanaged code would be the C++ stuff you're used to. Dynamic memory allocation and explicit freeing of the memory. The .NET runtime does not manage the memory for you, hence 'unmanaged'.
Managed code on the other hand IS managed by the run-time. You allocate memory where required (by declaring variables, not memory space) and the run-time garbage collector determines when it's no longer needed and cleans it all up. The garbage collector will also move memory around to improve efficiency. The run-time 'manages' it all for you.
As I mentioned above, it is possible to write code that is both managed and unmanaged.
Unmanaged:
class Bar : public Foo {
private:
int fubar;
public:
Bar(int i) : fubar(i) {}
int * getFubar() { return * fubar; }
}
Managed:
public ref class Bar : public Foo
private:
int fubar;
public:
Bar(int i) : fubar(i) {}
int ^ getFubar() { return ^ fubar; }
}
Notice the ref? That pretty much designates a Managed class. It gets very confusing when you mix the two kinds of code however. For instance, you want to save a reference pointer, (^) the managed equivalent of a pointer, to a Picture Box control within your unmanaged class. Since the garbage collector can move memory around, the next time you try to dereference the picture box it can not be found. The run-time does not tell your unmanaged code about it's memory changes.
Therefore you need to pin down the managed object in memory to allow your unmanaged code to keep track of it. Then there's unboxing and all kinds of other quirks that allow you to intermix the two. Code complexity is enormous!
Officially, managed/unmanaged might come down to the way code executes on the .NET stack. However, if you're coming from a c++ background, I hope this will be a little more relevant to you.

Managed means that the code is not compiled to native code, and thus runs under the auspices of a virtual machine. Java compiles to an intermediate format called bytecode, which the Java VM knows how to interpret and execute. All the .NET languages do a similar thing, compiling to IL (intermediate language) which the .NET runtime interprets. It's a little confusing because the .NET IL have .dll and .exe file endings.

The term managed is generally applied only to .NET because Microsoft uses the term. Microsoft generally doesn't use the term "virtual machine" in reference to a .NET managed execution environment.
.NET's "bytecode" (IL) is somewhat different from Java bytecode in that it was explicitly designed to be compiled into native code prior to execution in the managed environment, whereas Java was designed to be interpreted, but the concept of platform-independent code is similar.
The ".NET Framework" is basically a huge set of libraries provided by Microsoft, containing thousands of classes that can be used to develop applications.
A compiled C# .exe contains platform-independent code that can be run in any .NET-compatible environment, including Mono. However, the runtime is generally distributed separately from applications that use it.

At the risk of offending some, I suspect that the word managed was used so they could use the word unmanaged instead of compiled. While managed may mean more, the reality is it seems to be the used to distinguish mostly between what is pretty much just in time compiling (as the replacement for what was one once interpreted or pcode) and native compiled code.
Or put another way, which would you prefer to use:
a) Unmanaged code that may do uncontrollable things to the system.
b) Native compiled code that is fast, solid and is close to the OS.
Of course, they are actually the same thing.

In a similar vein, is .NET a language or a framework, and what exactly does "framework" mean here? <<
.NET is Microsoft's current enterprise software platform. It consists of:
• A single universal interface for accessing Windows functionality:
o The .NET Framework Class Library (FCL).
o The FCL provides a rich set of high-level functionality for developers.
• A single universal language and runtime for executing .NET applications:
o Common Language Runtime (CLR) executes Common Intermediate Language (CIL).
o The CLR is God: it runs, controls, and polices everything.
• The choice of multiple languages for developing .NET applications:
o Every development language is compiled to CIL, which is run by the CLR.
o C# and VB are the two main development languages.

.NET is a framework. The Common language Runtime (CLR) executes the Microsoft Intermediate Language (MSIL) code that is generated when a solution is compiled (i.e., it does not compile to machine code). You cannot contain the API within the exe, nor would you want to as it is quite large. The major benefit here is memory management (among some other security advantages and possibly others that I do not know about.)

I can answer the framework question. .NET is a framework, C#, VB.NET, etc are languages. Basically .NET provides a common platform of libraries to call (All the System.... dlls) that any language using .NET can call. All the .NET languages are compiled into MSIL (Microsoft Intermediate Language, better known as just IL) which can then be run on any PC with the appropriate .NET framework installed.

.NET is a framework.
It can be used from many languages (VB.NET, C#, IronPython, boo, etc)
.NET always executes as interpreted, and no you cannot include the 'VM' inside the .exe. Any user wishing to run your .NET app must have the framework installed.

It can refer to any code executed by a virtual machine rather than directly by the CPU.
I think this enables things like garbage collection and array bounds checking.

Personally, I think the word "framework" is a bit of a misnomer.
.NET is a "platform", consisting of an execution environment (the CLR virtual machine) and a set of libraries. It's exactly analogous to Java or Perl or Python (none of which are ever referred to as "frameworks").
In most cases, the word "framework" is used for projects like Spring or Struts or QT, which sit on top of a platform (ie, providing no execution environment of their own) like a library.
But unlike a "library", a framework seeks to re-define the fundamental operations of the underlying platform. (Spring's dependency injection defies the constructor-calling logic of ordinary Java code. QT's signals-and-slots implementation defies ordinary C++ code.)
I know I'm just being a pedantic bastard, but to me, .NET is not a framework. It's a platform.

Managed Code--MSIL and IL and Managed Code are same.When we build our application the .dll or .exe files are generated in the Bin folder.These files are called as Managed code.Later these files are given to CLR to generate Native code which would be understood by OS.