When I did mostly c++ I though it was critical to know assembly and wrote some non trial asm code just so that I could truly understand what was going on. I now do mostly .net and while I have some understanding of IL I am by no means proficient.
Is IL a skill that one should have a knowledge of or will learning IL more completely go on to inform how I use and write .net code?
Learning IL completely is like learning assembly, in many ways.
Having an understanding of IL can help you understand what happens when you're actually compiling your .NET code. This can be very helpful, especially if you ever run into performance critical profiling situations (where you've found a real problem, and need to optimize it).
However, for most "day to day" programming tasks, I don't think it's really necessary to understand the IL, just like most C++ programmers don't really need to know how to write assembly.
That being said, if you understand assembly code with a C++ background, getting a general idea of IL will be very, very easy...
If you are just trying to write a .NET app you don't need any working knowledge of IL code. Most .NET developers do not know how to write in IL code.
IL will help you if you are trying to understand what is truly going on. You can use it to write more efficient code on a machine, that might not be obvious in the .NET language you are writing.
Depends. Knowing IL will probably help you understand what your code turns into. If you have a good knowledge if IL, you can even create new components at run-time (if you need to). Is it essential? Probably not.
Knowing assembly was very good for C/C++ in Visual Studio. You could always go to disassembly to see what is going on.
If you try the same in C#, i.e. "Go to disassembly" you still go to native code, not IL. In that sense IL is not as useful as real assembly.
But IL is good for looking inside assemblies that you don't have the source code too. (But you could use reflector for that)
Aside from the obvious (implementing a virtual machine), certain types of tasks demanded a pretty thorough understanding of IL.
One of the most interesting aspects to me personally is examining the impact of the IL language on the just-in-time compiler. One notable example contrasting the JVM and the CLI is the CLI has a notion of a non-virtual methods and direct dispatch, which allows especially efficient calls to be emitted by the non-optimizing (baseline) compiler. This analysis is more expensive in the JVM, so the baseline compiler can't optimize as many cases.
In general, .NET developers should not need to worry about learning CIL. If your work involves runtime/dynamically-generated methods, then you should evaluate the ability of the Expressions API to meet your needs because it is tremendously more usable/maintainable. I spent a few weeks emitting CIL with the ILGenerator. It took me one sitting to convert to Expressions, saving over a hundred of lines of code and fixing old bugs I just hadn't figured out.
A detailed knowledge of CIL is very important for anyone implementing a CLI virtual machine or writing compilers (AOT or JIT). I find it both interesting and useful, but in the scope of "important things to know to be a productive developer," it's just not that high.
There's only really one place in the .NET framework where you have to know IL, the classes in the System.Reflection.Emit namespace. It lets you generate code on the fly, that can be useful in select cases.
The best way to get exposure to IL is through the Ildasm.exe tool, Reflector could work too. A very convenient way to run it is by adding it to the Tools menu. Tools + External Tools, Add.
You can now write some managed code, compile and quickly take a look at the generate IL. You'll find it pretty easy going if you've been exposed to machine code before. Just keep in mind that IL is untyped, the same opcode is used for any value type.
The next step is to take a look at how IL gets translated to machine code. Start debugging, right-click the code and choose Go To Disassembly. Beware that you won't look at the real machine code unless you run the Release build and enable JIT optimization. Tools + Options, Debugging, untick "Suppress JIT optimization on module load".
No, like most said. Plus, to add to their comments look at why you use C/C++ and why you use .NET and its languaes (liek C#):
C/C++ was made to give you power over a computer in a nice abstracted way. It is converted ALMOST directly into assembly language and gives you great power for good (and evil.) Things like pointers are encouraged and there is no garbage collection. Hence, you have to should know what the assembly language code is doing because of what you can do.
.NET languages were made to make great apps quickly and limit the damage you can do to these apps. It discourages you from using real power over the CPU (like pointers are discouraged and you need not worry about garbage collection for the most part.) Basically, the damage you can do is limited to the app; and little to do with the CPU (unless you dabble with unsafe code which is only used in rare cases [in my experience]). In addition, .NET code is converted to IL, then IL is converted to assembly and so on... you are not directly dealing with assembly language anyway.
These said, it is good to know IL for head knowledge and can help you a little. But knowing it will not greatly help you create great app- which is the point of .NET languages for the most develop not working at Microsoft.