I had a few questions to ask for a beginner in IL Assembly.
1) How to code IL then use some tools to convert to c#? Is it possible? I had seens many articles that required you to code c#, convert to *.exe, then use ildasm to convert into IL. I want the opposite way.
2) Is there any way to debug IL codes like debugging c#? Placing breakpoints, can see how data is transfered?
3) I do notice that C++.NET do boxing when i write this code.
for (i=0; i<10; i++)
Does it mean c# doesn't do boxing behind the scene? Why?
4) Is there any guidelines that IL must be coded like this for C# and like that for VB.NET? It seems the generated codes (using ildasm) for c# and vb.net are a bit different. Hope can write 1 IL and use for everything.
5) Is there any benefits to code IL and be hardcore on it? Does the industry needs people who is good in .NET and good in IL too?
Thanks. IL looks great
1. Check out .NET Reflector. It should be able to show you some C# code for a given assembly regardless of whether it was originally compiled with ilasm or any other compiler. Here's a link:
2. The Visual Studio debugger doesn't support "disassembling" to IL. Not sure about other tools out there.
3. Console.WriteLine has several overloads including one that takes an Int32. In the C++ code snippet you provided, you're explicitly boxing the value before passing it to Console.WriteLine. If you don't do that, it should probably just work without boxing.
The C# compiler will automatically box the int if it needs to. In the case of Console.WriteLine, it doesn't need to. If you use something that just takes an object, such as ArrayList, then you'll see that C# will box it for you.
4. The VB and C# compilers don't always emit exactly the same IL. But it'll probably be pretty similar for the most part. I think the simple answer to your question is yes, it's one IL for everything. There are features supported by the CLR that are not
supported by all .NET languages. But in general, interop between languages is great.
5. Someone who can read IL will be able to better understand what the code they wrote in a higher-level language (C#, VB, etc.). We, on the compiler team, read IL very often. It's one of the first steps we take when trying to figure out if a bug is in the
compiler or the JITter or elsewhere. That said, I'm not sure it's a huge advantage to know IL fluently in general. It'll sure help, but I don't know of many people that find themselves writing code in IL very often.
Note though that you are essentially reverse-engineering generated code, what you get won't be the same, although similar to, as if you coded it in a high-level language yourself. Also, since anyone with one of these tools can reverse engineer any .Net IL assembly
-- even copyrighted, commercial software, there is a push to obfusicate, or attempt to make it harder, to reverse-generate code in this manner.
#2: I don't know the answer to this question -- I played around a little bit in VS and under the debug menu was able to attach to an already running .Net process and was able to set breakpoints, however, the source displayed was actual assembly language, not
#4: I'm not completely sure on this question -- but I'll try it is my understanding that any .Net language gets compiled to pure IL code and thus IL is more or less exactly the same -- hence the full name of IL being "Common Intermediate Language". It thus
just depends on the ability of the disassembler to reverse engineer IL into whatever higher-level language which the user would want. The differences in IL I believe are due to minor semantics of each language. Also be aware that other various differences
may be due to differing timestamps, filesize, assembly version, and module version GUID... but there also might be additional metadata, I don't know..
#5: My opinion on this one -- the advantage of coding in a high level language -- such as VB.Net, C#, but even C++, C or any other high level language is that the code is easier to view, debug, and maintain. The benefits writing code in IL probably are the
same arguments for writing native assembly code in that you can control every variable, every pointer, every method call, every stack push, every stack pop, . The disadvantages are that you're controlling every variable, every pointer.. you get the idea..
As far as needing IL coders, perhaps this would be a valuable skill in creating compilers for other OS's/Platforms.. (such as the mono (http://www.go-mono.org) project is doing) Crafting custom languages, and aid in debugging..
there's probably alot more too..
Note that included in the framework are these namespaces:
the first allows for generating runtime assemblies and modules, the second emitting IL code at runtime through an extensive object module, and the third contains classes which can be used to generate programmatically source code.
Looks like this got answered much more concisely by someone who knows what they're talking about so I'll quit
Thanks a lot. Yeah, i roughly know what to do next. Thanks again. Yummy IL taste sweet.
On sourceforge.net .The DILE tools could debug IL code.
If you want to get a deep view into the .NET runtime you should read the
ECMA-355 standard (aka. Common Language Infrastructure standard).
Also if you want to know more about IL you can also try: MS Press - Inside .NET IL Assembler
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.