Is C# partially interpreted or really compiled?
C# is compiled into IL, by the c# compiler.
This IL is then compiled just-in-time (JIT) as it's needed, into the native assembly language of the host machine. It would be possible to write a .NET runtime that interpreted the IL instead though. Even if this was done, I'd still argue that c# is a compiled language.
A purely compiled language has some advantages. Speed, as a rule, and often working set size. A purely interpreted language has some advantages. Flexibility of not needing an explicit compilation stage that allows us to edit in place, and often easier portability.
A jitted language fits in a middle ground in this case.
That's a reason alone why we might think of a jitted language as either compiled or as interpreted depending on which position on which metric we care about attaining, and our prejudices for and against one or the other.
C# can also be compiled on first run, as happens in ASP.NET, which makes it close to interpreted in that case (though it's still compiled to IL and then jitted in this case). Certainly, it has pretty much all the advantages of interpreted in this case (compare with VBScript or JScript used in classic ASP), along with much of the advantages of compiled.
Strictly, no language is jitted, interpretted or compiled qua language. We can NGen C# to native code (though if it does something like dynamically loading an assembly it will still use IL and jitting). We could write an intepretter for C or C++ (several people have done so). In its most common use case though, C# is compiled to IL which is then jitted, which is not quite the classic definition of interpreted nor of compiled.
Too many semantics and statements based on opinion.
First off: C# isn't an interpreted language; the CLR and JVM are considered "runtimes" or "middleware", but the same name applies to things like Perl. This creates a lot of confusion among people concerned with names.
The term "Interpreter" referencing a runtime generally means existing code interprets some non-native code. There are two large paradigms: Parsing reads the raw source code and takes logical actions; bytecode execution first compiles the code to a non-native binary representation, which requires much fewer CPU cycles to interpret.
Java originally compiled to bytecode, then went through an interpreter; now, the JVM reads the bytecode and just-in-time compiles it to native code. CIL does the same: The CLR uses just-in-time compilation to native code.
Consider all the combinations of running source code, running bytecode, compiling to native, just-in-time compilation, running source code through a compiler to just-in-time native, and so forth. The semantics of whether a language is compiled or interpreted become meaningless.
As an example: many interpreted languages use just-in-time bytecode compilation. C# compiles to CIL, which JIT compiles to native; by contrast, Perl immediately compiles a script to a bytecode, and then runs this bytecode through an interpreter. You can only run a C# assembly in CIL bytecode format; you can only run a Perl script in raw source code format.
Just-in-time compilers also run a lot of external and internal instrumentation. The runtime tracks the execution of various functions, and then adjusts the code layout to optimize branches and code organization for its particular execution flow. That means JIT code can run faster than native-compiled code (like C++ typically is, or like C# run through IL2CPP), because the JIT adjusts its optimization strategy to the actual execution case of the code as it runs.
Welcome to the world of computer programming. We decided to make it extremely complicated, then attach non-descriptive names to everything. The purpose is to create flamewars over the definition of words which have no practical meaning.