The .NET Framework was designed and developed from day one to be Internet aware and Internet enabled. It uses technologies such as HTML, SOAP, and XML as its underlying methods of communication. As a developer, you have the option of probing as deeply as you wish into each of these technologies, but with the .NET Framework you have the luxury, if you want, of staying completely ignorant of them.
You have probably heard that .NET is language neutral. This key feature of .NET is handled by the CLR. It is currently possible to develop code using C++, C#, J#, JScript .NET, and Visual Basic .NET. In the future, many other languages will be supported. All .NET-compatible languages have full access to the .NET Framework class library. I cover .NET multilanguage support briefly in this chapter.
Another thing you have probably heard whispers about is that .NET can be platform independent. This means that it is possible to port the .NET Framework to non-Windows platforms and then run it without recompiling .NET applications and services. The reason for this is that .NET-compatible code is compiled into something called assemblies, which contain code, along with several other things, in an intermediate language. I cover assemblies briefly in this chapter and then delve into the art of programming with them in Chapter 17.
It is true that the .NET Framework can be ported, but as of now this has not happened. Microsoft states that it has plans to do so, but no details have been disclosed as of this writing.
If you've been coding and deploying Windows code in C++ for any length of time, I'm sure you've become painfully aware that it's anything but simple. Now, if you've gone beyond this to build distributed applications, the complexity has multiplied many times over. A key design goal of the .NET Framework is to dramatically simplify software development and deployment. Some of the most obvious ways that the .NET Framework does this are as follows:
It shelters you from the complexities of the raw Windows application programming interface (API).
It provides a consistent, self-documenting object model.
Managed code provides garbage collection. You no longer have to worry about memory loss due to your forgetting to delete allocated pointers. In fact, if you use managed code, you don't even have to deallocate pointers because the .NET Framework will do it for you.
Managed code is made up of only managed objects, and unmanaged code is made up of unmanaged objects. This book only discusses managed code.
The intricacies of COM and COM+ have been removed. To be more accurate, COM and COM+ are not part of the .NET Framework. You can continue to use these technologies, but .NET supports them by placing COM and COM+ components in a class library derived wrapper. You no longer have to worry about things such as the VARIANT, IUnknown, IDL, and so on.
Deployment components no longer use the registry or special directories. As an added bonus, there is no more DLL Hell.
Deployment is frequently as simple as an xcopy.