About compiling and running C# apps

My C# books are pretty much mentioning this with one sentense. But I like to know what is going on under the hood here. And I don't get it 100%.



When you compile a C# app. Then it is compiled to MSIL? Right/Wrong?

and then when you run it, then it is actualy compiled to native language?




If both of these are true. Does that mean that when you compile it on a Win platform. Can you then take it to a linux machine that has the ,NET framework and run it there. BUT if you first run it on the Windows machine after you compiled it there, you can't bring it over to a Linux machine? Or is it "compiled" to native code every time you start the app? (not likely).

All this seems a bit weird to me. What did I not understand?


ØØ

Its a concept called "Just In Time" (JIT) compilation. When you go to execute a .NET assembly, the .NET VM compiles it into native code and caches it for future use. When the cached copy becomes out of date, because of a recompile, or whatever, a fresh copy is compiled again from the assembly.

So you can use the assembly anywhere that has the framework. The original assembly is not affected by the JIT compiler.

Ohhh...so the natvie code is cashed somewhere else then in the binary file that is compiled???



I read this, and that was why I started to wonder:

Quote:

---

This is actually a common misconception. I mean you state that one of the languages runs on a VM but neither of the languages you stated do.

Maybe you just don't understand how C# and the .NET framework are working under the hood? Maybe you just didn't know that C# compiles to MSIL code and on first run is JIT on the fly and compiled to NATIVE code and never touches any type of VM?

---

He says C# apps isn't touching any VB at all. Is that right?



ØØ

He's right. Why would it? C# and VB are separate languages. Live like VB6 and C++ are separate. Where commonalities are is in the Framework itself. When you access System.Data.String, it's the same object in both VB.NET and C#. Unlike previously, they would have been in different DLL (msvbrunXX.dll & msvcrun.dll)

When you compile a VB.NET or C#.NET proggie, it gets compiled into a IL object, that is "finished" upon execution via the JIT compiler.

Tg

But when it gets "finished". Does it use the a VM then?

And if I understood crptcblade right, you can still take the compiled version with you too an other OS with the .NET framwork. Because it will again be "finished" off by the JIT compiler?

THere is no VM. THere's nothign virtual about it. Once it's "finished" it runs as a fully compiled unit and is cached. As for being able to freely move he assemblies around from OS to OS.... I don't know. I haven't a need to do that so I've never tried it. Would be interested in the results though.

Something in the back of my brain says it can't be that easy, there *has* to be a catch.

Tg

Quote:

---

Originally Posted by techgnome

THere is no VM. THere's nothign virtual about it. Once it's "finished" it runs as a fully compiled unit and is cached.

---

Thanks. Got it now...:)...I need it smacked in my for head to understand thing...:)

Quote:

---

Originally Posted by techgnome

As for being able to freely move he assemblies around from OS to OS.... I don't know. I haven't a need to do that so I've never tried it. Would be interested in the results though.

Something in the back of my brain says it can't be that easy, there *has* to be a catch.

Tg

---

Yeah, it sounds a bit too god to be true. But it would be interesting to hear if anyone have tried it. Well it works for java, so why not...but it isn't done 100% in the same way though.



ØØ

JIT compiler is the workhorse . It takes the exe file loaded in memory and compiles it to native code . This is why it takes sometimes(well most of the time) too long for any .NET exe file to execute .My 2cents .:D

You can Ngen the assembly, in which case it is not JIT compiled - and you won't experience the lag on the first build.

There are of course some drawbacks - none I deem critical or pertinent to most applications. In NoteMe's case, you could't Ngen a .Net assembly on Win platform and expect it to work on Linux (because its pre-compiled to native code).

But you could copy the assembly over to Linux, and Ngen it there.

Sorry to be fool here, but what is NGen, and how do you do that?


ØØ

ngen is a command line utility that comes with the SDK. It takes the IL from the assembly and compiles it to native code.

Thanks. Sounded like an buildt-in function in the IDE when he said it..:)



ØØ