NET solution provides a set of framework classes and lets every language use it. Such a framework removes the need for learning a new API each time you switch languages. Put differently, it's certainly easier to go through ten methods of a particular class than to go through a thousand API functions.
1.3.5 Simple Deployment
Imagine this scenario: your Windows application, which uses three shared DLLs, works just fine for months, but stops working one day after you've installed another software package that overwrites the 13
first DLL, does nothing to the second DLL, and adds an additional copy of the third DLL into a different directory. If you have ever encountered such a brutal—yet entirely possible—problem, you have entered DLL Hell . And if you ask a group of seasoned developers whether they have experienced DLL
Hell, they will grimace at you in disgust, not because of the question you've posed, but because they have indeed experienced the pain and suffering.
To avoid DLL Hell on Windows 2000 (at least for system DLLs), Windows 2000 stores system DLLs in a cache. If you install an application that overwrites system DLLs, Windows 2000 will overwrite the added system DLLs with the original versions from the cache.
Microsoft .NET further diminishes DLL Hell. In the .NET environment, your executable will use the shared DLL with which it was built. This is guaranteed, because a shared DLL must be registered against something similar to the Windows 2000 cache, called the Global Assembly Cache (GAC). In addition to this requirement, a shared DLL must have a unique hash value, public key, locale, and version number. Once you've met these requirements and registered your shared DLL in the GAC, its physical filename is no longer important. In other words, if you have two versions of a DLL that are both called MyDll.dll, both of them can live and execute on the same system without causing DLL Hell.
Again, this is possible because the executable that uses one of these DLLs is tightly bound to the DLL
during compilation.
In addition to eradicating DLL Hell, .NET also removes the need for component-related registry settings. A COM developer will tell you that half the challenge of learning COM is understanding the COM-specific registry entries for which the developer is responsible. Microsoft .NET stores all references and dependencies of .NET assemblies within a special section called a manifest (see Chapter 2 ). In addition, as semblies can be either private or shared. Private assemblies are found using logical paths or XML-based application configuration files, and public assemblies are registered in the GAC; in both cases the system will find your dependencies at runtime. If they are missing, you get an exception telling you exactly what happened.
Finally, .NET brings back the concept of zero-impact installation and removal. This concept is the opposite of what you have to deal with in the world of COM. To set up a COM application, you have to register all your components after you have copied them over to your machine. If you fail to perform this step correctly, nothing will work and you'll pull your hair out. Likewise, to uninstall the application, you should unregister your components (to remove the registry entries) prior to deleting your files.
Again, if you fail to perform this step correctly, you will leave remnants in the registry that will be forever extant.
Unlike COM, but like DOS, to set up an application in .NET, yo u simply xcopy your files from one directory on a CD to another directory on your machine, and the application will run automatically. [2]
Similarly, you can just delete the directory to uninstall the application from your machine.
[2] This is true for private assemblies, but not for shared assemblies. See Chapter 4 f or more details.
1.3.6 Reliability
There are many programming languages and platforms in the commercial software industry, but few of them attempt to provide both a reliable language and a robust runtime or infrastructure. The most successful language that we have seen in the commercial software industry is the Java™ language and the Java Virtual Machine™, which have brought the software-development community much satisfaction. Microsoft is positioning .NET as the next big thing.
Microsoft .NET requires type safety. Unlike C++, every class in .NET is derived from the mother of all classes, Object, which supports runtime type-identification features, content-dumping features, and so on. The CLR must recognize and verify types before they can be loaded and executed. This decreases the chances for rudimentary programming errors and prevents buffer overruns, which can be a security weakness.
14
.NET Framework Essentials
Traditional programming languages don't provide a common error- handling mechanism. C++ and Java support exception handling, but many others leave you in the dust, forcing to invent your own error-handling facilities. Microsoft .NET supports exceptions in the CLR, providing a consistent error -
handling mechanism. Put another way: exceptions work across all .NET-compatible languages.
When you program in C++, you must deallocate all heap -based objects that you have previously allocated. If you fail to do this, the allocated resources on your system will never be reclaimed even though they are no longer needed. And if this is a server application, it won't be robust because the accumulation of unused resources in memory will eventually bring down the system. Similar to Java, the .NET runtime tracks and garbage-collects all allocated objects that are no longer needed.
1.3.7 Security
When developing applications in the old days of DOS, Microsoft developers cared little about security because their applications ran on a single desktop with a single thread of execution. As soon as developers started developing client and server applications, things got a bit complicated: multiple users might then have accessed the servers, and sensitive data might be exchanged between the client and the server. The problem became even more complex in the web environment, since you could unknowingly download and execute malicious applets on your machine.