【正文】 out what the offending DLL is and have the customer replace the new one with the version that works with your software. Now their new software doesn’t work wele to DLL Hell. Many developers resort to simply installing every DLL their application requires in the application directory so that it will be found first when the application loads the libraries. This defeats the purpose of shared libraries, but it is one way around the problem. COM was going to change this: one of its primary tenants was that you never changed the method interface you simply add new methods. Unfortunately, software developers are frequently perfectionists, and leaving a “broken” function alone just chafes some people. Problem is that changing a ponents interface once it’s in use can have adverse affects on the client software that expected the old behavior. Because COM objects are loaded using information in the Registry, simply placing the DLL or controlling in the application directory doesn’t work for this problem. The .NET architecture now separates application ponents so that an application always loads the ponents with which it was built and tested. If the application runs after installation, then the application should always run. This is done with assemblies, which are .NETpackaged ponents. Although current DLLs and COM objects do contain version information, the OS does not use this information for any real purpose. Assemblies contain version information that the .NET Common Language Runtime uses to ensure that an application will load the ponents it was built with. We cover more of the specifics of how assemblies and versioning works later in the chapter. Support for Open Standards Currently, not every device you may want to work with is going to be running a Microsoft OS or using an Intel CPU. As for this point, the architects of .NET are relying on XML and its most visible descendant, SOAP, an emerging standard for sending messages across the Internet that activates programs or applications regardless of their underlying infrastructure. SOAP will provide the means for disparate systems to exchange information easily, but even more, SOAP allows you to invoke methods on remote systems and return the results immediately. Because SOAP is a simple textbased protocol similar to HTTP, it can easily pass through firewalls, unlike DCOM or CORBA objects. Other standards employed by the .NET platform include Universal Description, Discovery, and Integration (UDDI), a directory of panies and their XML interfaces and the Web Services Description Language (WSDL), which describes what a piece of application code can do. By basing much of .NET on open standards and by submitting the proposed draft standards for C and the .NET Common Language Infrastructure to ECMA, an international standards organization, Microsoft hopes to see its version of the future of software adopted beyond its own domain. Easy Deployment To date, developing installations for Windowsbased applications can be incredibly difficult, to the point that most panies use third party tools for developing their installation programs, and even then it’s not pleasant. There are usually a large number of files to be installed in several directories, various Registry settings, installation of required COM ponents, and shortcuts that need to be created, and so on. Completely uninstalling an application is nearly impossible, most leave bits and pieces of themselves around even if they provide an uninstall feature. With the release of Windows 2000, Microsoft introduced a new installation engine that helps with some of these issues, but it is still possible that the author of a Microsoft Installer Package may fail to address every problems. Even with those third party tools specifically designed to make developing installation programs easier, it is still frequently a monumental task to correctly install a retrieval application. The .NET design team might have recognized this problem, because .NET plans to do away with these issues for good. .NET ponents are not referenced in the Registry, thanks to the use of metadata and reflection, ponents are self describing. In fact, installing many .NET applications will require no more than copying their files to a directory, and uninstalling an application will be as easy as deleting those files. Distributed Architecture Today’s distributed applications are much different from those we would see in the future. Microsoft certainly believes that they are betting the pany on the concept of distributed Web services. For example, when interacting with a portal site, it appears to seem that they are working with a remote server. Most know that it is normally not the case, at least for a site of any significant size. There are various servers and applications behind the scenes as well as accessing information on several remote sites, bining it with information from their user database and merging all into an integrated product delivered to the user via their browser. As useful as these types of applications are, they are all very plex to develop and maintain. Each provider of information has developed different interfaces to access data and processes on their servers. This redundant development is grossly inefficient and for the most part fairly boring, so there has been a great deal of activity around three standards to streamline the process: XML, SOAP, and UDDI. As we discussed earlier, these are utilized in .NET and also in peting, less well known initiatives from IBM and Sun. Interoperability with Unmanaged Code As you can probably guess, unmanaged code is the code that is not managed by the .NET Common Language Runtime. However, this code can still run by the CLR, it just doesn’t get the advantages that it offers, such as the Common Type System and Automatic Memory Management. You will probably end up using unmanaged code in a couple of different situations: ■ Ca