The tools you listed are great tools for viewing the contents of .NET DLLs. ILSpy and .NET Reflector allow you export the code from the DLL into C# or VB.NET, but there are limitations to this.
I personally use ILSpy, which is as easy as opening the DLL, finding the class in question, then go to File->Save Code.
I haven't used .NET Reflector since Red Gate made it closed source and charged for it. When I did use it, it had a very nice feature that would export the entire assembly's contents into C# or VB.NET project as opposed to individual code files like ILSpy does.
There are also other tools out there that will achieve this. I know Telerik has one, but I believe it is a commercial product. JetBrains also has one called dotPeek that is free to use.
In order to understand your second question, the why, you need to understand how .NET works. Your .NET application is not compiled and linked into executable file like a C/C++ application is. Your application is compiled into an intermediate language (IL) or Microsoft Intermediate Language (MSIL) which is similar to Java's bytecode. Take a look at this article to understand IL a bit more in depth:
Understanding Common Intermediate Language (CIL)[
^]
In Windows, when you run a .NET application, the local computer takes the IL and performs a Just In Time compile (JIT) to produce native code that can run on the local computer. Take a look at this MSDN article to understand more about JIT:
Compiling MSIL to Native Code[
^]
The short answer to the why is simply your code hasn't been fully compiled until you run your application so the reverse engineering is fairly straight forward. There are limitations to this (linq queries, lamda expressions, obfuscator) where the tool may have an extremely hard time creating the exact code, but it will be able to give something functional.
I hope this helps.