【正文】 ines the size of the base data types that are available to .NET applications, and applications run within the Common Language Runtime environment, the application developer is insulated from the specifics of any hardware or operating system that supports the .NET platform. Although at the time of this writing .NET applications run only on Windows platforms, Microsoft announced that it had reached an agreement with Corel to develop a sharedsource implementation of a C piler and the .NET Framework infrastructure ponents for the FreeBSD version of UNIX on June 27th, 2021. This is currently expected to be available in a beta version sometime in the first half of 2021. A few weeks later, on July 10, 2021 Microsoft gave the goahead to an opensource version of .NET being planned by Ximian, the developer the popular GNOME user interface for Linux. You can find the project, called Mono, at . The group is developing a C language piler, along with the .NET Common Language Runtime .Work has also begun on the Base Class Library. The release of the first usable Project Mono code is planned for the end of 2021. Automatic Memory Management The mere mention of a memory leak problem brings forth images of endless hours of debugging for developers who have e from a development environment that did not offer automatic memory management. Even for those fortunate enough to work with this in some form have likely spent some time trying to hunt down obscure bugs caused by tricky code that circumvented the resource management methodology. Developers, specializing in Visual Basic or COM, are familiar with the reference counting technique. This technique recovers the memory used by an object when no other object has a reference to it, essentially when it is not needed any more. Although this is, to some extent, theoretically perfect, it has a few problems in practice. The most mon matter is the circular reference for one object contains a reference to another object which itself contains a reference back to the first object. When the memory manager looks for objects that are not in use, these objects will always have a reference count greater than zero, so unless they are implicitly deconstructed, their memory may never be recovered. For a C or C++ programmeraccustomed to ensuring that objects are properly destroyed, essentially managing memory on their ownthis sounds perfectly normal, 重慶大學(xué)本科生畢業(yè)論文翻譯 13 and a good reason for not trusting anyone else to take care of managing resources. However, in the .NET environment, Microsoft is striving to make developing software easier. Later in this chapter, we cover a how .NET garbage collection works, and the improvements that have been made over strict reference counting or manual memory management approaches. Versioning Support Anyone who doesn’t understand the phrase ―DLL Hell‖ has not been developing (or at least supporting) software for Windows very long. For the uninitiated, you’ll find yourself in DLL Hell someday when a customer installs a software package that uses one of the same DLLs as your application. However, your application used version of this DLL, and the new software replaces it with version developers all always make sure everything is 100% backwardspatible, right? The new DLL makes your application exhibit some strange problem or perhaps just stop working altogether. After a lot of investigation, you figure 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 重慶大學(xué)本科生畢業(yè)論文翻譯 14 sending messages across the Inter 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