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.
Related
At the bottom of pg 86 in Pro .NET Performance - Optimize Your C# Applications, it talks about the implementaton of ValueType.Equals() and says this:
The definition of CanCompareBits and FastEqualsCheck is deferred to the CLR, they are "internal calls", not implemented in IL
What exactly are "internal calls" and what language are they implemented in if not IL?
Methods, like mentioned CanCompareBits or FastEqualsCheck are marked with [MethodImpl(MethodImplOptions.InternalCall)], which informs clr that it needs to find implementation in it's internals. In terms of CLR it's called FCall, see Calling from managed to native code
Since coreclr is opensourced it's easy to find actual implementation on github.
For FastEqualsCheck see comutilnative.cpp.
CoreCLR is written with C++ as well as Mono, so all code for all such internal calls is C/C++.
In runtime, in opposite to regular .net code which will produce IL (Intermediate language), such internal calls is platform-dependent assember instructions
The language the Common Language Runtime is written in or compiled into. Unfortunately as there are many different Runtimes/Interpreters for IL Code, I can not tell you any more precise without you telling me wich specific one we are talking about.
.NET Programms are compiled into the Intermediate Language. The IL is then run by the CLR. If you think that sounds like Java Bytecode being executed by the Java Application - you are damn right! It was most definitely an inspiration. It is a step up too, however.
For several points of view, .NET Programms are as interpreted as a Batch File, Java ByteCode, JavaScript or PHP/Python script. There are some things all of those can do, that they will not make available for Programms running in them.
When I was learning .NET I saw it as a platform that runs my .NET programs which has its own Stack & Heap.
But now after learning more about things, I see a .NET application as just like any other C/C++ native application. It is in Portable Executable (PE) file format with new data directory & .text section is filled with MSIL code instead of machine code. The only difference is few DLLs (which are considered as .NET platform) (like any other Dll dependency) are loaded.
I guess at the very entry point there is some machine code which calls into the loaded DLL(.net platform) and functions of those DLL read the MSIL from .text section (segment to be more correct) and generate equivalent machine code and put it in some kind of buffer (I don't know which area would it be it. I cannot be .text & .data as they are readonly. will they be stack or heap?). Then make the EIP point to this buffer of instructions. Last few instructions again call back into DLLs to repeat the process for rest of MSIL.
As of Managed Heap & Managed Stack they are just some portion of the processes heap & stack. its just that few functions (referred to as GC) will keep track of the memory allocations & deallocations from this portions of memory.
I like this realistic view. I don't know how far I'm true. I'm just guessing these things. Please correct me & tell me more about this. How far will is it similar to this view? Where can I learn more about .NET platform from this point of view?
You missed one very important point - CIL code (formerly MSIL) is safe code. You cannot do arbitrary pointer voodoo, type casting or similar evil things (except for some in unsafe code regions). This is probably the most important difference to other languages like C(++), Pascal and so on. This safety guarantees are deeply build into the language, type system and runtime design.
For CLR check : CLR via C#.
It is really a great book especially if you are interested in "low level" .NET/CLR.
For JVM check : Java Virtual Machine
CLR via C# describes some internal .NET things, including PE load process and hosting of CLR in your own process.
Your description is missing one thing: most code in a .NET assembly is just-in-time (JIT) compiled, meaning that the MSIL isn't converted into machine code until the moment just before the method is called for the first time, at which point it's cached for the future. This greatly speeds up startup time, at the cost of a minor slowdown the first time each method is called. (I omit details like the fact that the JIT compiler may re-optimize the function after it's been called a few times.)
The JIT-compiled code lives on the heap, from the perspective of the OS. The JIT compiler will mark the code as executable and do whatever other voodoo is necessary to make it run correctly.
It's not 100% accurate, but I'd say you've got a decent overview of certain portions of the framework down.
If you'd like to know more, I suggest you take a look first at the .NET Framework FAQ and when you're done with that read the .NET 1.1 Inside the .NET Framework series of articles. These articles won't cover many of the advances that have occurred over the last 4 versions, but they'll give a good, solid foundation of what the .NET Framework is all about.
Lately I have been reading Pro C# 2008 and the .NET 3.5 Platform (there's now a VS2010/.NET 4.0 version, too), and it does a great job explaining how the .NET bytecode works on the back-end, and how you can learn about what's really being called by using the reflector, etc. It's dense and long (and sometimes more info than I wanted), but it's good informative reading.
You might find this MSDN article interesting: http://msdn.microsoft.com/en-us/magazine/cc163791.aspx
As well as these books:
http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463/ref=pd_bbs_sr_1/104-0844985-7433557?ie=UTF8&s=books&qid=1175791950&sr=8-1
http://www.amazon.com/CLR-via-Dev-Pro-Jeffrey-Richter/dp/0735627045/ref=sr_1_1?ie=UTF8&s=books&qid=1277838859&sr=1-1
Is there any major advantage of managed C++/CLI over C#. Definitely not the syntax I suppose as the following code in C++/CLI is real ugly,
C++/CLI code:
[Out]List<SomeObject^>^% someVariable
Compare above with C# Code:
out List<SomeObject> someVariable
Just out of curiosity, is there an even uglier syntax in C++/CLI as compared to the above.
It's almost exclusively an interopability language - both for allowing .Net code to access legacy C++ libraries, or for extended existing (native) C++ code bases with access to .Net libraries (and some variations on these themes).
While it is possible to write fully fledged applications solely in C++/CLI, and it even gives you some language features not available in pure C++ (such as garbage collection), I doubt there are many people who would actually do this. If you're already moving away from pure C++ and don't have the goal of interop with .Net there are probably more natural choices (such as D or Scala, for example - depending on which direction you want to go in).
Similarly, moving from pure C# to C++/CLI could arguably bring the advantages of C++ templates, but it's rare that this need would lead to you taking that step.
Easier interoperation with native C++ code is the one advantage.
Whether it's a major advantage is subjective.
Unless you want to mingle with existing native C++ code, you're probably much better off with C#.
I can think of 3 main reasons to use C++/CLI:
You already have a large C++ project and want to use .NET in it (whether you want to migrate it completely in the future or not)
You want to use a library written in C or C++. For simple libraries, you can use C#/PInvoke, but e.g. if the libary comes with a complex type system, you might be better off creating C++/CLI wrappers instead of recreating the type system in C#
Parts in your project are best written in C++. E.g. if you're doing speech recognition or image processing, C++ might simply be better suited for the task.
Being able to use native headers files directly is a huge advantage, but not the only one.
Stack semantics are so much better than anything C# has to offer for IDisposable management. C++/CLI has one uniform syntax for correctly managing variables which are IDisposable and those which aren't, both as local variables and as member fields. Comparison:
ref class MyClass
{
FileStream fs;
}
vs
class MyClass : IDisposable
{
FileStream fs;
void IDisposable.Dispose() { Dispose(true); }
~MyClass() { Dispose(false); }
public virtual void Dispose(bool disposing) { if (disposing) fs.Dispose(); }
}
Now which language is looking ugly?
Then there are templates, interior_ptr, #define, native DLL exports, pointer-to-member, and probably several other things I've forgotten.
Using C++/CLI it is much easy to interact with native C++ code
The advantage of managed C++ is that it is easy to mix managed and unmanaged code. But if all (or almost all) of your code will be managed, then C# should definitely be used (and you can still invoking unmanaged code from C# using the DllImport attribute).
CLI/C++ has many advantages over C#.
STD libraries
Native C++/C cannot be viewed by disassembler (like Reflector) because they are not actually CLI (no need to obfuscate (although a good hacker can already get by this)).
Mingling C/C++ projects as a wrapper to be used with .Net languages. C++/CLI is not a language is just adds support for .Net with C/C++.
Some bit of control on memory via C/C++ pointer pointing to C/C++ objects on the heap.
I hate having to trust in GC to get to an object stuck on the gen 2. Lord knows when that will be released from the managed heap.
Being a predominantly C# programmer, I was finding myself having to use C++/CLI with a bit of pain. However, as an interop language, it FAR outweighs C# for having to work with native code. The C++/CLI IDE in Visual Studio lacks a lot of the features in the C# flavor.
Overall, it has its place and will remain viable as long as native code exists. I wouldn't want to have to create WinForm apps from scratch with the C++/CLI IDE if I didn't have to.
you just turn to c++\cli when you have to, if you can meet you requirement using c#, why bother go c++\cli
Generally, I think the main advantage of C++/CLI is simply familiarity for C++ developers. If you're not coming from a C++ background then go with C#.
unmanaged c++ applications do not need a framework to run, c# will only run on machines with dotnet framework 1, 2, 3 or 4. it surprising how many machines still run without these framework.
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? 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.