Question

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...

Was it helpful?

Solution

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.

OTHER TIPS

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.

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

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top