How does C# work?

Question

Mono

Hello. While learning C#, I'm trying to somehow compare it with Java and I can't understand some points that seem clear to me in Java.
1. As far as I know, Java has a JVM that loads .class files containing bytecode and runs them. In the C# world, there is a CLR that handles MSIL. And where does this MSIL come from? Where are .cs compiled? All I found is just an .exe file, but at what point does the virtual machine then work, and why do we get an .exe output?
2. In the C# world, there are also such concepts as .NET, Mono, Roslyn, etc., can you explain their meaning in a structured way?
It is not necessary to describe everything here, you can just give links to articles where all these concepts are collected, I will be grateful. Wikipedia is not welcome, everything is too fragmented. Thank you.

Answer 1

> As far as I know, Java has a JVM that loads .class files containing bytecode and runs them.
Correction: usually not .class, but .jar. But inside the .jar (this is an archive) there are already .class files. After all, .class, as the name implies, contains only 1 class, something like .obj in C ++. And in the application there can be several classes, + digital signature, + other. Here all this is also linked in .jar.
The same .jar works everywhere where there is a pure JVM. Works on desktop Linux. It does not work on Android, instead .apk is a different format.
> Where are .cs compiled?
Google csc.exe
Usually all operations are carried out in it, i.e. from .cs can immediately make .exe. Although it is possible to first make IL (something like assembler, but not yet bytecode, i.e. NOT binary), but IL is already compiled into bytecode (binary format) with an exe wrapper.
> In the C# world, there are also concepts such as .NET, Mono, Roslyn, etc., can you explain their meaning in a structured way?
The .NET Framework includes:
- compilers: for C# (the same csc.exe) and not only for C# (yes, compilers are included in .NET, not in Visual Studio);
- the same CLR;
- several class libraries such as mscorlib.dll, System.Windows.Forms.dll (Winforms). WPF libraries. Such libraries are called standard. Those libraries that are not included in .NET and need to be dragged along with the exe are called third-party, since they are usually created not by MS, but by third-party, "third" developers.
Mono is a platform positioned as a cross-platform alternative to the .NET Framework. That is, everything listed there is their own and there is nothing from MS. The IDE also has its own - MonoDevelop.
In fact, this alternative from start to finish is very raw and generally frail. For example, Winforms / WPF is simply not there (maybe you can screw these assemblies from .NET, but it will not work on Linux without Vine, and MonoDevelop does not contain tools for convenient development for them). Instead of Winforms / WPF there is GTK#, it is really cross-platform, but it is very far from Winforms and even more so WPF.
Roslyn - some new compiler from MS, it seems to be an alternative to the old csc.exe. I personally don't see anything interesting in it.

Answer 2

I recommend Richter's book "CLR via C#"

Answer 3

And where does this MSIL come from? Where are .cs compiled?

cs are compiled by the compiler. There is a standard csc, it comes with the .net framework (NOT with the studio). This is a "classic" compiler from MS, written in C++, closed source. The same is for Visual Basic. In addition to them, there are also Roslyn C# and VB compilers, they are open-source, their main difference is that they themselves are written in managed languages. This means that you have a compiler-as-a-service. This, in turn, means that if you want to write a tool that processes source code in one way or another, for example, in C #, you do not need to write a parser / compiler yourself, you can connect Roslyn compiler modules and use the SAME compiler (lexer /parser/etc), which is used directly when building the application. This will not work with the classic compiler, it is a black box: cs at the input,
Further, we will assume that we do not take into account the .net native technology in the reasoning.
it works at the moment of start exe.
there is often confusion on this issue. The fact is that dotnet exe and dll are the so-called. assemblies, and they contain metadata and MSIL (!) executable code. The fact that they have exe and dll extensions is because MS has packaged them in PE format to improve compatibility and usability. So that .net applications can be run in the same way as native ones. BUT in reality, there is only a small loader in the exe file that starts the CLR, asks to load the current file as a dotnet assembly and transfer control to the entry point method. Read about assemblies in a good book, and download dotPeek, see what's inside the dotnet exe. This is not at all what is in the "normal", native exe.
.NET is the name and brand of the platform, .NET Framework, and now .NET Core - platform implementations from MS, Mono - open-source implementation NOT from MS. .NET FW only works on Windows, .NET Core and Mono and other platforms. I already mentioned Roslyn.

Answer 4

MSIL is just the result of compiling c#. And it is he who is contained in the exe. It's just that this exe starts the .net machine and tells it where the MSIL is in the exe.