The above diagram summarizes the architecture; let's look at the each item from the bottom,
Before starting with .Net application execution let's recollect how a normal C program works.
We write our C code in plain ASCII code, the C compiler converts the ASCII code to binary code (.exe), this binary code will be executed by the operating system.
But in case of .Net, the compiler will not generate binary code from the ASCII code, instead the compliers will generate only the MSIL (MicroSoft Intermediate Language) from the ASCII code. This MSIL will then be converted to binary or native code by the CLR depending upon the target OS. That is why we need CLR to execute any .Net application as the processor cannot understand the MSIL code they understand only the binary code.
Why? Why do we want to convert the ASCII to MSIL first then to Native? What is the advantage do we get?
The reason why do we go for the MSIL step is that, we are getting most of the benefits of .Net through this MSIL, for e.g. resource management, object lifetime management, reflection, type safe, some debugging support, etc. To avail these benefits we go for the MSIL step. And these benefits make the developer's life very easy. Finally we, the developers are rewarded with this MSIL.
Is .Net Platform Independent?
Before answering this question let's recollect what is platform independence. It can be defined as 'compile the code in one platform and run it in any platform'. To be clear the compiler should not generate any platform specific code as compiler output.
How java is platform independent? Java compiler generates byte code as complier output. This byte code is platform independent. And java has JVM for different platform, the byte code can run on any JVM i.e. any platform. Thus the generated byte code is platform independent.
Coming back to .Net, as we saw, our .Net compliers generates the MSIL code and this MSIL will run on CLR. This MSIL is not platform specific i.e. it can run on any platform if CLR for the platform is available. But Microsoft has not provided CLR other than Windows platform. So .Net technology is platform independent but we don't have CLR for other platforms from Microsoft.
Identifying a .Net application:-
We saw that we need CLR to run any .Net application. Consider you have two EXEs. One is .Net exe and other one is normal windows application exe. Both are located in your C drive. When you double click on an exe the OS (Windows) will handle the click event and will run the exe in the processor. But incase of .Net exe the CLR has to be loaded to execute the .Net application. So how does the OS know to load CLR incase of .Net application? To answer this question let's understand the parts of a .Net assembly/exe.
Any .Net assembly/exe has the following four sections.

PE Header is a normal COFF header used by the operating system. When we double click on any exe the instruction inside this section will be executed by the OS. In our case, for .Net applications this section will redirect the OS to the CLR header section.
CLR Header, this is a different section which we have only in .Net assemblies. This section contains some instructions to load the CLR. This part of header section is responsible to load the CLR (if not been loaded already) when we try to execute a .Net application. Till now the control is in the hands of OS, after the CLR is loaded the CLR will take the control of the application from the OS and the CLR will execute the .Net application. Now the CLR will execute the application from the Main method available in the MSIL section.
Metadata, initially we saw that all the .Net assemblies are 'self describing'. This metadata section is responsible self description. This section will contains all the information about the assembly like list of namespaces, classes it has and methods in each class, parameters, etc.
MSIL, implementation of all the methods, classes, etc. available in the assembly will be there in this section in MSIL format. As we saw this is not in binary format. MSIL is like another assembly language.
Does Language Matter?
We have VB.Net, C#, VC++.Net, J#, etc. languages. Does choosing a language for an application affects the performance or usability of framework? The answer is NO. All the compliers generate the MSIL code. Microsoft has provided these many languages to support different syntax. If you are familiar with VB syntax then you can go for the VB.Net language, if you are familiar with VC++ syntax you can go for the VC++ language. Choosing a language does not affect the usage of .Net framework. Al the framework libraries are available for all the languages. And as all the compliers generate the MSIL it doesn't have any impact on the runtime too. If you are new to any syntax it is good to use C# as it has got more features.
CLS/CTS:-
As we saw we have many .Net languages but all the languages produce the MSIL as output. This MSIL is common. So the target types are shared by all the languages. These target type are the types that is defined in the MISL. And all the languages have to obey some rules for generating the MSIL like syntax and types. The rules that should be followed by any .Net languages are called CLS or Common Language Specification. And there are some set of types in the MSIL that should be supported by any language as a minimum requirement. These set of types are called CTS or Common Type System. There are some types outside the CTS, but these type are optional may be supported by a language. Each language will have its own boundary like the following diagram.

In the above diagram we could see that all the languages supports the CTS minimally and some extra types. And diagram also shows all the languages obey the rules defined in the CLS. We achieve the interoperability through this CTS. Since all the .Net languages are expected to support CTS it is guaranteed that types inside this CTS are fully interoperable.
Having said about CTS/CLS it is also possible to write your own .Net language which will have your own syntax. But while developing the complier you should keep in mind that you support all the CTS Types and obey the rules specified in CLS.