Aww, that would of been really awesome if you could but I guess you just can't have one part not use the .net and the other part use .net? Makes Sense.
It's more complicated than that. But I'm willing to explain because I recently whiteboarded this all out for some friends.
So .NET's DLLs are not actually "native"/machine code
... They actually have human-readable (but it can be tough) code called CIL - Common Intermediate Language code.
C and C++ produce native language code which is binary code that the processor can read and execute. Even though .NET refers to the CIL DLL files as "assemblies," they are completely on a different spectrum from actual C/C++ DLLs/.EXE files.
What happens with C# when you build your application is it gets turned into CIL code that I mentioned above, then you actually distribute that CIL code... You never actually distribute* machine-language code to your customers/clients basically.
This is why C# code requires whats called the .NET runtimes/.NET Framework/CLR (take your pick, they all mean the same thing basically) to run. The .NET Framework has another program that is "always on" in the background of computers that have it installed called the JITer, which stands for Just-In-Time Compiler. The JITer interprets the CIL code that is in your C# DLLs and files, then AT RUNTIME (when the user actually double clicks the executable
, it gets finally compiled down into actual machine code on a case-by-case basis
. What this means is that only the parts of your program that the user actually needs to use get compiled as needed, rather than your entire program.
So if a user only uses a few functions in your program ever, the rest of the program will actually never be compiled to machine code ever. With C and C++, all of that doesn't exist, your entire program
just goes straight to machine code and you are distributing machine code. Note that there are different ways to link your code in such as dynamic or static linking, but nevertheless, it's still compiled down to machine code all the time.
That whole .NET process has its ups and downs, but generally, it requires unnecessary bloat and overhead (the user must have the .NET Framework installed or else the code obviously is completely useless), plus there is performance loss associated with so many layers of abstraction involved. Because of the bloat required to run the CIL/C# code, for example, you cannot program small embedded devices which have limited memory with C# because they cannot fit the .NET runtime crap on their chips. It's like with anything: You get more convenience and it comes at a cost... That is, if you find C difficult, which many people like Casey do not. I actually find C easier than C# aside from occasional memory quirks.
The upside is that the CIL code, because it is compiled at run-time (when the user executes the program) into machine code rather than by the programmers right away, it can do things like examine what type of machine it is running on and then try to optimize the actual machine code for that type of machine. Another cool thing (I guess), is that since multiple languages are part of .NET and all compile to the CIL, technically your buddy can program in Visual Basic.NET
and you can program in C#, and they will end up being the exact same code anyway and can be packaged/work together pretty easily.
That's all I'm going to explain because other things get murky, if you go check StackOverflow, you'll find guys arguing back and forth about the pros and cons of all of this, and whether or not the CIL code resembles "Bytecode" which is basically Java's version of the CIL.
And don't feed into the hype, we're all entitled to our own opinions of course, but I'm of the school-of-thought of Casey
when he thinks the whole .NET/JVM thing is a load of crap, but that's just me. That said, I am a C# programmer and I do use C#, I just prefer C whenever possible. In the end, if you are satisfied and the game works well, who cares? :)
*I've heard it's possible
to actually pre-compile C# code into actual machine-code ahead of time but I've never done this and it doesn't seem to be a widespread practice. Even still, not sure how that would align with C code.