# C# .NET Web Developers Guide P2

Chia sẻ: Thach Sau | Ngày: | Loại File: PDF | Số trang:20

0
102
lượt xem
19

## C# .NET Web Developers Guide P2

Mô tả tài liệu

Introducing the Microsoft .NET Platform 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++ programmer—accustomed to ensuring that objects are properly destroyed, essentially managing memory on their own—this sounds perfectly normal, 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...

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: C# .NET Web Developer`s Guide P2

1. 8 Chapter 1 • Introducing the Microsoft .NET Platform 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++ programmer—accustomed to ensuring that objects are properly destroyed, essentially managing memory on their own—this sounds per- fectly normal, 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” hasn’t been developing (or at least supporting) software for Windows very long. For the uninitiated, you’ll ﬁnd yourself in DLL Hell someday when a customer installs a software package that uses one of the same DLLs as your application. However, your appli- cation used version 1.0 of this DLL, and the new software replaces it with version 1.1.We developers all always make sure everything is 100% backwards-compat- ible, right? The new DLL makes your application exhibit some strange problem or perhaps just stop working altogether. After a lot of investigation, you ﬁgure 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… welcome to DLL Hell. Many developers resort to simply installing every DLL their application requires in the application directory so that it will be found ﬁrst 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 a methods interface you simply add new methods. Unfortunately, software developers are frequently perfectionists, and leaving a “broken” function alone just chafes some people. Problem is, changing a components 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 control in the application directory doesn’t work for this problem. The .NET architecture now separates application components so that an application always loads the components with which it was built and tested. If the application runs after installation, the application should always run.This is done with assemblies, which are .NET-packaged components. 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 www.syngress.com
2. Introducing the Microsoft .NET Platform • Chapter 1 9 .NET Common Language Runtime uses to ensure that an application will load the components it was built with.We cover more of the speciﬁcs of how assem- blies and versioning works later in the chapter. Support for Open Standards In today’s world, not every device you may want to work with is going to be running a Microsoft OS or using an Intel CPU. Realizing this, 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 appli- cations 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. Because SOAP is a simple text-based protocol similar to HTTP, it can easily pass through ﬁre- walls, unlike DCOM or CORBA objects. Other standards employed by the .NET platform include Universal Description, Discovery, and Integration (UDDI), a directory of companies 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 Today, developing installations for Windows-based applications can be incredibly difﬁcult, to the point that most companies use third party tools for developing their installation programs, and even then it’s not pleasant.There are usually a large number of ﬁles to be installed in several directories, various Registry set- tings, installation of required COM components, 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 installa- tion engine that helps with some of these issues, but it is still possible that the author of a Microsoft Installer Package may fail to do everything correctly. Even with those third party tools speciﬁcally designed to make developing installation programs easier, it is still frequently a monumental task to correctly install a retrievial application. www.syngress.com
3. 10 Chapter 1 • Introducing the Microsoft .NET Platform The .NET design team must have felt the same way about this problem, because .NET plans to do away with these issues for good. .NET components are not referenced in the Registry, thanks to the use of metadata and reﬂection, components are self describing. In fact, installing many .NET applications will require no more than copying their ﬁles to a directory, and uninstalling an appli- cation will be as easy as deleting those ﬁles. Developing & Deploying… Using the Visual Studio.NET Setup Tools Realizing that deploying applications and authoring installation pack- ages is frequently a monumental task, the Visual Studio.NET team inte- grated a number of setup tools into the Visual Studio.NET environment. After you have completed your Visual Studio.NET project develop- ment, start a new project from the File menu. Choose Setup and Deployment Projects from the selection list. You’ll see a number of setup project options listed: s Cab Project s Deploy Wizard s Merge Module Project s Setup Project s Setup Wizard s Web Setup Project Using the wizards, you can select the Visual Studio project you want to use and have a setup or deployment project created automatically. If the defaults are not sufﬁcient for your needs, you can use the new setup project as a basis for creating your custom setup or deployment. Distributed Architecture Today’s distributed applications are much different than those we will see in the future. Microsoft certainly believes this; they say they are betting the company on the concept of distributed Web services. www.syngress.com
4. Introducing the Microsoft .NET Platform • Chapter 1 11 For example, today when a user is interacting with a portal site, it appears to them that they are working with one remote server. Most of us know that is nor- mally not the case, at least for a site of any signiﬁcant size.There are various servers and applications behind the scenes are accessing information on several remote sites, combining it with information from their user database and merging it all into an integrated product that is delivered to the user via their browser. As useful as these types of applications are, they are all very complex to develop and maintain. Each provider of information has developed different interfaces to access data and processes on their servers.This redundant develop- ment is grossly inefﬁcient 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 used in .NET and also in competing, less well known initiatives from IBM and Sun. Interoperability with Unmanaged Code As you can probably guess, unmanaged code is code that isn’t managed by the .NET Common Language Runtime. However, this code is 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 unman- aged code in a couple of different situations: s Calling DLL functions There is a lot of functionality locked inside DLLs today. Not every company is going to rush to deliver a .NET component version of their products, so if you need to interface with them, you’ll be calling unmanaged code. s Using COM components This is likely to be for pretty much the same reasons you might be required to call DLL functions. s Calling .NET services from COM components Although this sounds a little odd, it is possible. A COM client can be made to call a .NET component as though it was a COM server. Here’s a little more information on the COM interoperability issue. Microsoft didn’t want to force companies to abandon their existing COM components; especially because many of Microsoft’s own products are COM-based today. COM components interoperate with the .NET runtime through an interop layer that handles all the work required when translating messages that pass back and forth between the managed runtime and the COM components operating as unmanaged code. www.syngress.com
7. 14 Chapter 1 • Introducing the Microsoft .NET Platform Performance and Scalability Let’s face it—there is no magic bullet that will allow a poorly designed applica- tion to scale well.What the .NET Framework is giving you are tools to make it easier to design better performing software. One big gain for Web development will come from ASP.NET’s improved support for keeping code, data, and presen- tation separate. .NET offers features for transaction handling and component pooling, but makes them easier to use than they were in previous incarnations, so more development will be likely to take advantage of them.The .NET Base Class Library has an enormous set of functionality, which means that you will have to write less basic code and spend more time reﬁning the features and performance of your applications. New versions of Microsoft software christened with the .NET emblem offer improved performance over earlier versions. SQL Server.NET offers quite an enhancement over earlier versions of the database engine, and other server prod- ucts offer enhanced scalability as well.When you redesign an application around the .NET Framework, take advantage of the latest advances all around and see what the results are. Components of the .NET Architecture As we mentioned earlier, there is a lot to the .NET Framework. In this section, we identify the individual components and describe their features and how they ﬁt into the overall picture. .NET Runtime The heart of the .NET Framework is the CLR. Similar in concept to the Java Virtual Machine, it is a runtime environment that executes MSIL code. Unlike the Java environment, which is the concept of one language for all purposes, the .NET platform supports multiple programming languages through the use of the Common Language Speciﬁcation, which deﬁnes the output required of com- pilers that want to target the CLR. Managed/Unmanaged Code Because all code targeted at the .NET platform runs with the CLR environment, it is referred to as managed code.This simply means that the execution of the code and its behavior is managed by the CLR.The metadata available with man- aged code contains the information required to allow the CLR to manage its safe www.syngress.com
8. Introducing the Microsoft .NET Platform • Chapter 1 15 execution. By safe execution we mean memory and security management, type safety, and interlanguage interoperability. Unmanaged code can write to areas of memory it does not own, execute instructions at arbitrary locations in memory, and exhibit any number of other bad behaviors that cannot be managed or pre- vented by the CLR. Most of the applications running on Windows today are unmanaged. Intermediate Language The .NET intermediate language, MSIL, is deﬁned in the Common Language Speciﬁcation. It is an amalgam of a low-level language similar in many ways to a machine language and a higher object language.You can write applications directly in MSIL, much as you can write directly in assembly language.Thankfully, this is not necessary for most purposes. Common Type System .NET applications, regardless of their source languages all share a common type system.What this means is that you no longer have to worry when doing devel- opment in multiple languages about how a data type declared in one language needs to be declared in another. Any .NET type has the same attributes regardless of the language it is used in. Furthermore, all .NET data types are objects, derived from System.Object. Because all data types derive from a common base class, they all share some basic functionality, for example the ability to be converted to a string, serialized, or stored in a collection. .NET Base Class Library (BCL) If I could have bought a library that offered everything the .NET Base Class Library offers when I started programming, a year’s salary would have seemed reasonable—there really is that much to it. Almost everything in the .NET envi- ronment is contained within the BCL. Let’s look at a “Hello World” example: using System; class Hello { public static void Main() { www.syngress.com