LDD Part 1: Understanding .NET
So for those who are taking the best advantage of .NET, here's a little background that may help you understand how everything actually works in the managed world.
First, managed code (what we call .net code) behaves a lot differently than the standard types of applications people used to build in the COM days. First difference, they can't run by themselves. In other words, that .NET executable file on your hard disk (what is called an assembly), isn't native machine code, like all the other .EXE files. It needs a runtime "host" to make it work. This host, called the Common Language Runtime (or CLR), provides a whole bunch of very cool (and long overdue) services to managed applications.
1) It automatically manages memory for your applications (including cleaning up after your code, called garbade collection)
2) It includes VERY rich security support baked in. A managed application doesn't just get the user's permissions on the machine. It has it's own distinct permission set, based on all sorts of evidence collected about the application
3) It provides JITing services (Just in time compilation), so that your .EXE file (or .DLL or whatever, in other words, your assemblies), get compiled to native, machine language on first run, or on deployment
4) It ensures something called type safety. More on this in a minute.
5) It has no language preferences. All languages that target the CLR must comply with the Common Language Specification (CLS) which causes them to compile their source code to an intemediate, assembler-like language, called Microsoft Intermidiary Language (MSIL). This is what is actually contained in your .exe or .dll file on disk.
6) VB.NET performs just as well as C# !
There are numerous treaties on the CLR around, check out the resources section of Last Developer Standing to find tons of great links to this material.
I did mention that I'd talk about type safety. So, in the past, people wrote applications using tons of different languages (C/C++ and VB being common on Windows) and talked to Databases (SQL Server, Oracle, etc.). And each of these provided their own type systems. These are things like variables, structures, enumerations, etc. The key here is that the way each of these technologies represented their types in memory might be completely different. For example, a string in C++ is not represented the same way as a string in VB. This causes developers to have to jump through all kinds of loops to try and get programs that use different technologies, and causes unexpected unfortunate system occurences when types get mismatched.
In the managed environment, all data types are managed for you by the common language runtime. Languages share the same type system. So a string in C# is the same as a string in VB.NET is the same as a string in J#. Not only that, but the CLR will prevent you from inadvertently doing unsafe casts between types. This is called type safety. For example, let's look at some C# code:
double d=32.55;
int q=3
q=d // error, this conversion would cause an unexpected loss of precision
This code won't compile. To get it to compile, you have to EXPLICITLY do the conversion. for example:
double d=32.2323;
int q=0;
q = System.Convert.ToInt32(d);
(I think this is right :)
This is probably one of the most common causes of application errors today, and the problem is, until the managed environment and the new compilers, these problems were not generally caught until a runtime error popped up, or you got unexpected results.
The type safety in .NET absolutely rocks, and prevents dolts like me from making very common and probable mistakes when writing code!
Tomorrow, we'll drill into the structure of an assembly, and then we'll talk about code access security, so we can address how a .net application eventually comes to life when it's launched.
(BTW, please forgive any technical lattitudes I may have taken in the above post).