Hi! I'm not an IL expert, but I can answer a few of your questions, as well as my opinion of using IL in this way..
I hope the experts of IL respond to this so that we can both learn more about IL..
#1: Going from IL to C# or other higher level language is called disassembly or decompiling. A number of tools are available on various sites, a quick google turned up this site:
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