programming microsoft .net

8/17/2019 Programming Microsoft .NET

1/621

Copyright © 2002 by Jeff Prosise


2/621

PUBLISHED BYMicrosoft PressA Division of Microsoft CorporationOne Microsoft WayRedmond, Washington 98052-6399

Copyright © 2002 by Jeff ProsiseAll rights reserved. No part of the contents of this book may be reproduced or transmitted in anyform or by any means without the written permission of the publisher.

Library of Congress Cataloging-in-Publication Data

Prosise, Jeff. Programming Microsoft .NET (core reference) / Jeff Prosise. p. cm.

Includes index. ISBN 0-7356-1376-1 1. Microsoft.net framework. 2. Microsoft software. 3. Internet programming. I. Title.QA76.625 .P76 A73 2002005.2'76-dc21 2002016626

Printed and bound in the United States of America.

1 2 3 4 5 6 7 8 9 QWE 7 6 5 4 3 2

Distributed in Canada by Penguin Books Canada Limited.

A CIP catalogue record for this book is available from the British Library.

Microsoft Press books are available through booksellers and distributors worldwide. For further information about international editions, contact your local Microsoft Corporation office or contact Microsoft Press International directly at fax (425) 936-7329. Visit our Web site atwww.microsoft.com/mspress . Send comments to [email protected] .

Active Directory, ActiveX, BizTalk, IntelliSense, JScript, Microsoft, Microsoft Press, MSDN,Visual Basic, Visual C++, Visual Studio, Win32, Windows, and Windows NT are either


3/621

registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company,organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Acquisitions Editor: Ann HamiltonProject Editor: John PierceTechnical Editor: Marc Young


4/621

Dedication

To Abby


5/621

Acknowledgments

Iâ€™d like to take a moment to thank the numerous people who contributed to the production of this book and lent their unselfish support to the person who wrote it.

First, a tip of the hat to John Pierce, wordsmith par excellence, and Marc Young, who is the most

thorough technical editor Iâ€™ve ever had the pleasure of working with. Both are veterans of many books and are among the best in the business at what they do. I hate to even think aboutwhat this book would look like had it not been for them.

Next, a profound thanks to the colleagues whom I pressed into service to read chapters and provide technical feedback: Francesco Balena, Jason Clark, John Lam, John Robbins, KennScribner, and Dave Webster. Iâ€™m especially indebted to Jeffrey Richter for sharing with mehis deep knowledge of the .NET Framework.

Special thanks also to the many people inside and outside Microsoft who answered my questionsand helped me overcome technical obstacles. The list includes, but is not limited to, Peter Drayton, Rob Howard, Erik Olson, and Brent Rector.

And lest I forget, a heartfelt thanks to Microsoft Press illustrator Rob Nance, who got me out of a jam when I needed comic book covers for the sample programs in Chapter 6. Also toMicrosoftâ€™s Anne Hamilton, who allowed me the opportunity to write this book and waited

patiently for me to deliver, and Claudette Moore, my agent and longtime friend, who pressed meto get this project off the ground.

Finally, to my family: my wife, Lori, and my children, Adam, Amy, and Abby. Writing a book ishard work. This time around I proved that itâ€™s harder on the authorâ€™s family than it is on

the author himself. These four endured a lot while I spent endless days and nights laboring over the manuscript, and words canâ€™t express how good it feels to know that theyâ€™re alwaysthere for me, rooting for me every step of the way.

Look, kids. Iâ€™m done!


6/621

Introduction

Yes, itâ€™s that time againâ€”time to throw away everything you know and start all over. Theera of Microsoft .NET has arrived, and with it comes a promise to change software developmentas we know it. Microsoft .NET is many things, but first and foremost itâ€™s a better way towrite software in an Internet-centric world. To benefit from .NET, youâ€™ll find it helpful to let

go of any preconceived notions and prepare yourself to think about software in a whole newlight. That means shedding comfortable clothing such as the Windows API, MFC, and COM,and immersing yourself in new ways of developing and architecting software that are unlikeanything youâ€™ve seen before.

When I began writing this book in July 2001, I had been working with the .NET Framework SDK for more than a year. The .NET Framework was in beta at the time and was still monthsaway from emerging as a released product. When I first laid eyes on it, I expected to seesomething that resembled COM. What I saw instead was a radical departure from anythingMicrosoft had done before and a better way to write software. If your companyâ€™s plans

include Web apps, Web services, or other applications that use the Internet as their platform,there simply is no better way to write those applications than to use Microsoft .NET. I would nomore consider writing a Web app today with ASP than I would consider using a wrench to drivenails. The first ingredient for a successful software project is picking the right tool for the job. If your job involves Web programming (and maybe even if it doesnâ€™t), Microsoft .NET is justthe tool that you need.

This book is about Microsoft .NETâ€”what it is, how it works, and how to write software thatuses it. Among other things, youâ€™ll learn about the common language runtime (CLR) and thehighly structured environment that it provides for executing code compiled from C#, Visual

Basic .NET, and other languages. Youâ€™ll learn about the .NET Framework class library(FCL), the stunningly comprehensive class library that provides the API managed applicationswrite to. Youâ€™ll become acquainted with the programming models embodied in the FCL,including Windows Forms, Web Forms, and XML Web services. And just as important,youâ€™ll learn how to make all the pieces work together to write sophisticated applications thatleverage the power of Microsoft .NET.


7/621

The Journey Ahead

Programming Microsoft .NET tells a storyâ€”the story of Microsoft .NET. You can read it from beginning to end and learn in step-wise fashion how to write software that targets the .NETFramework. The book is also structured so that individual chapters stand alone. If youâ€™re aseasoned .NET developer who simply wants to learn about multithreading, turn to Chapter 14 for

a detailed treatment of threads and thread synchronization. If itâ€™s custom ASP.NET server controls that float your boat, go straight to Chapter 8. The information you find there will helpyou get the job done with a minimum of wasted motion.

If you prefer the beginning-to-end approach, hereâ€™s what youâ€™ll encounter along the way.Part 1 of this book builds the foundation you need for understanding and profiting fromsubsequent chapters. Youâ€™ll become acquainted with the Microsoft .NET Framework, whichincludes the common language runtime and the .NET Framework class library. Youâ€™ll learnabout the frameworkâ€™s type system and about some of the more than 7,000 types included inthe FCL. Youâ€™ll also learn about one of the .NET Frameworkâ€™s most important

programming models: Windows Forms. Windows Forms lets you build GUI applications similar to the ones that are so prevalent in Windows today. Later on, in Chapter 15, youâ€™ll even learnhow to pair Windows Forms with the .NET Frameworkâ€™s remoting subsystem to build richclient apps that link to remote servers.

Part 2 is all about ASP.NETâ€”the portion of the .NET Framework that helps you build Webapplications and Web services. Web programming today is a black art built around HTML,DHTML, ASP, COM, and other loosely related technologies. Web programming tomorrow will

be a science, thanks to ASP.NET. If youâ€™ve tried Web programming before and donâ€™tlike it because you donâ€™t like dealing with slow, weakly typed scripting languages and find

browser DOMs more trouble than theyâ€™re worth, ASP.NET might just change your mind.Itâ€™s a true second-generation technology for building applications that run on the Web.Moreover, it brings compiled code, strong type safety, and (to a degree) browser independence toWeb programming. Chapters 5 through 11 cover ASP.NET in detail and impart the skills youneed to write cutting-edge ASP.NET Web applications and Web services.

Part 3 rounds out the book with detailed coverage of selected portions of the .NET Framework.Topics include ADO.NET, which provides a database access API for managed applications;XML and all the classes that the FCL provides for dealing with XML data; threading, or how towrite multithreaded code and coordinate the actions of concurrently running threads; and

remoting, which provides a framework for writing closely coupled distributed applications. Takethese chapters to heart and youâ€™ll be able to hold your own in conversations at .NET parties.


8/621

A Word About Programming Languages

One of the hallmarks of the .NET Framework is that it is language-agnostic. For the first time inhistory, it matters little what language you choose to write code in because in the end alllanguages exercise the same set of features in the .NET Framework.

I do all my coding in C#, in part because C# is the only language designed specifically with the.NET Framework in mind, and also, because Iâ€™m an old C++ guy, C# feels natural to me.Since Iâ€™m a C# programmer, the vast majority of the code samples in this book are written inC#, too. Few of the concepts presented in the book, however, relate only to C#. This book isabout programming the .NET Framework, and C# happens to be the vehicle that I use to expressmy thoughts. If you prefer Visual Basic .NET or COBOL instead, it is my hope that this book will be no less valuable to you. Once you know how to open a connection to a database withADO.NET, the code for actually doing it is remarkably similar whether itâ€™s written in VisualBasic .NET or C#.

Most of the samples in this book were written by hand, without the help of Visual Studio .NET.Thatâ€™s not a knock on Visual Studio .NET; itâ€™s evidence of my belief that learning is bestaccomplished by coding and not by having someone else code for you. Once you understandwhat goes into a Windows form or a Web form or a Web service, youâ€™ll find Visual Studio.NET an able partner in helping to create them. Writing applications the old-fashioned way firstwill increase your depth of understanding and better prepare you to work in an environment inwhich tools shoulder part of the load for you.


9/621

System Requirements

To compile and run the more than 75 sample programs included in this book, you must have the.NET Framework Software Development Kit (SDK) installed on your machine. The SDK runson Windows NT 4.0, Windows 2000, Windows XP, and presumably on later versions of Windows as well. The CD that comes with this book includes version 1.0 of the .NET

Framework SDK as well as Service Pack 1. When newer versions become available, you candownload them by pointing your browser to http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml. We all knowthat URLs change. If you go to this one and find that itâ€™s no longer valid, visit the Microsoft.NET home page at http://www.microsoft.com/net for the latest information on where to find theSDK.

Chapters 5 through 11 of this book, which cover ASP.NET, impose another requirement on your system. In addition to being outfitted with the .NET Framework SDK, your PC needs to haveMicrosoftâ€™s Web server, Internet Information Services (IIS), installed. Because ASP.NET

requires Windows 2000 or Windows XP, you need one of those operating systems, too. On theProfessional editions of these operating systems, IIS isnâ€™t part of the default installation. Toinstall IIS, open Add or Remove Programs in Control Panel and select Add/Remove WindowsComponents. Youâ€™ll find a check box for IIS. Be sure to install IIS before installing the SDK to make sure ASP.NET gets installed, too.

Some of the chapters in this book include sample programs built with Visual Studio .NET and provide Visual Studio .NETâ€“specific instructions. You donâ€™t have to have Visual Studio.NET to build code that targets the .NET Framework; the SDK comes with command-linecompilers. However, Visual Studio .NET offers a highly integrated development environment

that makes writing, testing, and debugging code easier. If you donâ€™t already own a copy of Visual Studio .NET, you can purchase one from Microsoft. For more information, visithttp://msdn.microsoft.com/vstudio/howtobuy.


10/621

Whatâ€™s on the CD

Programmers like goodies. The CD that comes with this book contains the following delectabledelights:

All of the bookâ€™s sample programs, source code included

A fully searchable electronic version of the book

The .NET Framework SDK version 1.0 and Service Pack 1

Youâ€™ll find instructions on the CD for installing the components that come on it. If AutoPlayis enabled on your PC, simply pop the CD in a drive to get started. In addition to being includedon the CD, the sample files are available for download fromhttp://www.microsoft.com/mspress/books/5200.asp.


11/621

Support

If you have comments about this book, questions you want answered, or errors to report, please post them at http://www.wintellect.com/forum/forum.asp?FORUM_ID=16. Iâ€™ll check themessage board regularly and do my best to respond. Others will monitor message traffic also and

jump in as appropriate. If you have a question, chances are someone else has one just like it. The

answer may already be posted. If not, by posting your question in a public forum, you enableothers to benefit from the answer as well.

I'd like to tell you that this book contains no errors, but of course I'd be lying. I've doneeverything humanly possible to verify the accuracy of every sentence and every code sample, buterrors will inevitably surface. Youâ€™ll find an up-to-date errata list athttp://www.wintellect.com/about/instructors/prosise/netbook.asp. If you don't want to fuss with along URL, simply go to http://www.prosise.com, and youâ€™ll find a link there.

If you'd like to contact Microsoft Press directly about this book or need to resolve packaging

problems (such as a defective or missing CD), you can contact them on line athttp://www.microsoft.com/mspress/support. If you prefer paper mail, the address is:

Microsoft Press

Attn:Programming Microsoft .NET Editor

One Microsoft Way

Redmond, WA 98052-6399


12/621

Blogs and Other Things That Go Bump in the Night

Ever wonder what itâ€™s like to write a book? When I wrote my first one in 1990, I learned thatwriting a book is an emotional roller coaster filled with peaks and valleys. The peaks are theelation that you feel when you describe a complex technical topic in a way that lifts the veil sothat others can understand. The valleys come from thinking of the sheer magnitude of the effort

that lies before you. Many is the time I wish I had kept a diary of that period in my life. AlthoughI vividly remember the incredible relief I felt when I packaged up the last chapter and dropped itinto a Fedex box (publishers still required printed manuscripts in those days), most of the day-to-day details of that experience escape me.

Thatâ€™s why I documented my experience writing Programming Microsoft .NET in my veryown book blog. â€œBlogâ€• is short for â€œWeb logâ€• ; itâ€™s a diary published on theInternet. People all over the world tracked my progress as I wrote this book by checking my(almost) daily blog entries. If youâ€™d like to relive the experience, you'll find the finished blogathttp://www.wintellect.com/about/instructors/prosise/blog.

Finally, a personal note. Thereâ€™s no shortage of Microsoft .NET programming books on themarket. Iâ€™m humbled that you chose this one, and I sincerely hope your investment in this

book pays for itself many times over. Enjoy!

Jeff ProsiseMarch 13, 2002


13/621

Part 1Essential ConceptsChapter 1Hello, .NETÂ

â€œA journey of a thousand miles must begin with a single step.â€•

Sixth century B.C. Chinese philosopher Lao TzuÂ

Software development today is an industry beset by incompatibilities. Modules written indifferent languages donâ€™t easily integrate. Programs run on separate machines must jumpthrough hoops to talk to each other. Applications developed for different operating systems are

built on incompatible APIs, making porting difficult. And as the industryâ€™s focus shifts fromstand-alone applications and client/server programs to applications that live and run on the Web,new kinds of incompatibilities appearâ€”incompatibilities between programming models that

have stood the test of time and models that have evolved without planning or forethought to fill avoid that needed filling. Instead of compiled languages, we have scripting languages. Instead of rich graphical user interfaces, we have HTML. And instead of object-oriented programming, wehave enterprise-class applications built with mixtures of procedural code, HTML, DHTML,XML, COM, and other unrelated technologies.

Microsoft has a vision of the future that addresses these issues and many more. That vision isembodied in an initiative called Microsoft .NET. Microsoft .NET, or simply .NET as it is morecommonly called, is a new way of building and deploying software that leverages standards suchas HTTP and XML to make interoperability a reality rather than a dream, and that relies on the

Internet to make software services available on an unprecedented scale. An important part of theinitiative is the .NET Framework, which is a platform for building and running .NETapplications. The framework isnâ€™t required for building .NET applications, but it makes thedevelopment process eminently easier and less time-consuming. Among its many benefits: it

brings object-oriented programming to the Web; it eliminates many of the most common anddebilitating kinds of software bugs; and it provides a common API for all languages, meaning thelanguage that you choose at the beginning of a project wonâ€™t paint you into a corner at theend.

This chapter is your first step on the road to becoming a .NET Framework programmer. In it,

youâ€™ll become acquainted with the frameworkâ€™s two core components: the commonlanguage runtime and the .NET Framework class library. Youâ€™ll learn about metadata,common intermediate language, managed modules, and assemblies. At the end of the chapter,youâ€™ll write your first framework application. The information you come away with willenrich your understanding of the .NET Framework and help you understand what goes on under the hood when you build and run the applications presented in subsequent chapters.


14/621

The Microsoft .NET Initiative

The term â€œMicrosoft .NETâ€• refers to a massive effort on Microsoftâ€™s part to get awayfrom traditional software development and to buildâ€”with help from partners all over theindustryâ€”the Internet into a service-oriented software platform. Read the documents that

provide an overview of .NET on Microsoftâ€™s Web site, and youâ€™ll encounter the term

â€œXML Web servicesâ€• repeatedly. An XML Web service is an application that runs on aWeb server and exposes callable API functions, or Web methods, to clients on the Internet. XMLis part of the name because Web services and Web service clients use XML to exchange data. AsXML Web services proliferate, the Internet will become a software platform with an API far richer than any operating system. Todayâ€™s applications rely primarily on operating systemservices. Tomorrowâ€™s applications will use Web services to validate credit card purchases,check the status of airline flights, and perform other everyday tasks. With luck, your favoriterestaurants will make their menus available via a Web service so that you can check the dailyspecials from the comfort of your computer desk.

Web services arenâ€™t something that Microsoft invented, nor are they proprietary to Microsoft.NET. Web services rely on open standards such as HTTP, XML, and SOAP. (SOAP, in caseyou donâ€™t know, is an acronym for Simple Object Access Protocol; itâ€™s an Internetstandard that describes how applications can interoperateâ€”that is, call methods on eachotherâ€”using HTTP and other protocols.) Because theyâ€™re an industry standard and not aMicrosoft standard, Web services are already proliferating on the Internet. Significantly, most of the Web services that are available today do not use the .NET Framework and do not run onWindows. Web services are about interoperability. Itâ€™s relatively simple to write a Webservice client that runs on Windows and invokes methods on a Web service running on Linux. Inthe future, online directories that are themselves Web services will enable companies to advertisetheir Web services. Need a Web service that exposes real-time stock quotes or shipment trackinginformation? Microsoft and others are building UDDI (Universal Description, Discovery, andIntegration) registries that make such information available on a global scale.

If XML Web services can be written without Microsoftâ€™s help, then what does Microsoft.NET bring to the party? Plenty. First, .NET validates the Web service concept by throwing theweight of an industry giant behind it. Second, Microsoft is busy writing Web services of its own,

promoting Web service initiatives such as .NET My Services, upgrading its enterprise server products to fit seamlessly into a service-oriented world, and upgrading Visual Studio and other development tools to speak the language of Web services. Third, and perhaps most important, isthat Microsoft .NET includes the .NET Framework. You can write Web services using x86assembly language if you want to, but the .NET Framework makes writing Web services so easythat just about anyone can write one. Youâ€™ll learn all about Web services and theframeworkâ€™s support for them in Chapter 11.


15/621

The Microsoft .NET Framework

The .NET Framework is a platform for building and running applications. Its chief components arethe common language runtime (CLR, or simply â€œthe runtimeâ€• ) and the .NET Framework classlibrary (FCL). The CLR abstracts operating system services and serves as an execution engine for managed applicationsâ€”applications whose every action is subject to approval by the CLR. The FCL

provides the object-oriented API that managed applications write to. When you write .NETFramework applications, you leave behind the Windows API, MFC, ATL, COM, and other tools andtechnologies youâ€™re familiar with, and you use the FCL instead. Sure, you can call a WindowsAPI function or a COM object if you want to, but you donâ€™t want to because doing so requirestransitioning from managed code (code run by the CLR) to unmanaged code (native machine codethat runs without the runtimeâ€™s help). Such transitions impede performance and can even bevetoed by a system administrator.

Microsoft .NET is chiefly about XML Web services, but the .NET Framework supports other programming models as well. In addition to writing Web services, you can write console applications,

GUI applications (â€œWindows Formsâ€• ), Web applications (â€œWeb Formsâ€• ), and evenWindows services, better known as NT services. The framework also helps you consume Webservicesâ€”that is, write Web service clients. Applications built on the .NET Framework are not,however, required to use Web services.

Next to XML Web services, the portion of the framework with the greatest potential to change theworld is ASP.NET. The name comes from Active Server Pages (ASP), which revolutionized Web

programming in the 1990s by providing an easy-to-use model for dynamically producing HTMLcontent on Web servers using server-side script. ASP.NET is the next version of ASP, and it providesa compelling new way to write Web applications thatâ€™s unlike anything that has preceded it.

Because ASP.NET is such an important part of the framework, and because the number one questionasked by developers in the software industry today is â€œHow do I write applications that run on theWeb?,â€• a large portion of this bookâ€”all of Part 2, in factâ€”is devoted to it.

But first things first. The key to understanding the .NET Framework and the various programmingmodels it supports is to understand the common language runtime and the FCL. The next severalsections discuss both and introduce other important concepts that are vital for learning how to writeWeb services and other managed applications.

The Common Language Runtime

If the .NET Framework were a living, breathing human being, the common language runtime would be its heart and soul. Every byte of code that you write for the framework either runs in the CLR or isgiven permission by the CLR to run outside the CLR. Nothing happens without the CLRâ€™sinvolvement.

The CLR sits atop the operating system and provides a virtual environment for hosting managedapplications. When you run a managed executable, the CLR loads the module containing theexecutable and executes the code inside it. Code that targets the CLR is called managed code, and itconsists of instructions written in a pseudo-machine language called common intermediate language,

or CIL. CIL instructions are just-in-time (JIT) compiled into native machine code (typically x86 code)at run time. In most cases, a given method is JIT compiled only one timeâ€”the first time itâ€™scalledâ€”and thereafter cached in memory so that it can be executed again without delay. Code thatisnâ€™t called is never JIT compiled. While JIT compilation undeniably impacts performance, its


16/621

negative effects are mitigated by the fact that a method is compiled only once during theapplicationâ€™s lifetime and also by the fact that the CLR team at Microsoft has gone toextraordinary lengths to make the JIT compiler as fast and efficient as possible. In theory, JITcompiled code can outperform ordinary code because the JIT compiler can optimize the native codethat it generates for the particular version of the host processor that it finds itself running on. JITcompiled code is not the same as interpreted code; donâ€™t let anyone tell you otherwise.

The benefits of running code in the managed environment of the CLR are legion. For starters, as theJIT compiler converts CIL instructions into native code, it enacts a code verification process thatensures the code is type safe. Itâ€™s practically impossible to execute an instruction that accessesmemory that the instruction isnâ€™t authorized to access. Youâ€™ll never have problems with stray

pointers in a managed application because the CLR throws an exception before the stray pointer isused. You canâ€™t cast a type to something itâ€™s not because that operation isnâ€™t type safe.And you canâ€™t call a method with a malformed stack frame because the CLR simply wonâ€™tallow it to happen. In addition to eliminating some of the most common bugs that afflict application

programs, code verification security makes it eminently more difficult to write malicious code that

intentionally inflicts harm on the host system. In the unlikely event that you donâ€™t want codeverification security, you can have it turned off by a system administrator.

Code verification security is also the chief enabling technology behind the CLRâ€™s ability to hostmultiple applications in a single processâ€”a feat of magic that it works by dividing the process intovirtualized compartments called application domains. Windows isolates applications from oneanother by hosting them in separate processes. An unfortunate side effect of the one-process-per-application model is higher memory consumption. Memory efficiency isnâ€™t vital on a stand-alonesystem that serves one user, but itâ€™s paramount on servers set up to handle thousands of users atonce. In certain cases (ASP.NET applications and Web services being the prime examples), the CLR

doesnâ€™t launch a new process for every application; instead, it launches one process or a handfulof processes and hosts individual applications in application domains. Application domains are securelike processes because they form boundaries that managed applications canâ€™t violate. Butapplication domains are more efficient than processes because one process can host multipleapplication domains and because libraries can be loaded into application domains and shared by alloccupants.

Another benefit of running in a managed environment comes from the fact that resources allocated bymanaged code are garbage collected. In other words, you allocate memory, but you donâ€™t free it;the system frees it for you. The CLR includes a sophisticated garbage collector that tracks references

to the objects your code creates and destroys those objects when the memory they occupy is neededelsewhere. The precise algorithms employed by the garbage collector are beyond the scope of this

book, but they are documented in detail in Jeffrey Richterâ€™s book Applied Microsoft .NETFramework Programming (Microsoft Press, 2002).

Thanks to the garbage collector, applications that consist solely of managed code donâ€™t leak memory. Garbage collection even improves performance because the memory allocation algorithmemployed by the CLR is fastâ€”much faster than the equivalent memory allocation routines in the Cruntime. The downside is that when a collection does occur, everything else in that process stopsmomentarily. Fortunately, garbage collections occur relatively infrequently, dramatically lesseningtheir impact on performance.

Programming Languages


17/621

Yet another benefit of running applications in a CLR-hosted environment is that all code reduces toCIL, so the programming language that you choose is little more than a lifestyle choice. Theâ€œcommonâ€• in common language runtime alludes to the fact that the CLR is language-agnostic.In other environments, the language you use to implement an application inevitably affects theapplicationâ€™s design and operation. Code written in Visual Basic 6, for example, canâ€™t easilyspawn threads. To make matters worse, modern programming languages such as Visual Basic and

Visual C++ use vastly different APIs, meaning that the knowledge you gain programming Windowswith Visual Basic is only marginally helpful if your boss asks you to write a DLL in C++.

With the .NET Framework, all that changes. A language is merely a syntactic device for producingCIL, and with very few exceptions, anything you can do in one language, you can do in all the others,too. Moreover, regardless of what language theyâ€™re written in, all managed applications use thesame API: that of the .NET Framework class library. Porting a Visual Basic 6 application to VisualC++ is only slightly easier than rewriting the application from scratch. But porting a Visual Basic.NET application to C# (or vice versa) is much more reasonable. In the past, language conversiontools have been so imperfect as to be practically useless. In the era of the .NET Framework, someone

might write a language converter that really works. Because high-level code ultimately compiles toCIL, the framework even lets you write a class in one language and use it (or derive from it) inanother. Now thatâ€™s language independence!

Microsoft provides CIL compilers for five languages: C#, J#, C++, Visual Basic, and JScript. The.NET Framework Software Development Kit (SDK) even includes a CIL assembler called ILASM, soyou can write code in raw CIL if you want to. Third parties provide compilers for other languages,including Perl, Python, Eiffel, and, yes, even COBOL. No matter what language youâ€™re mostcomfortable with, chances are thereâ€™s a CIL compiler that supports it. And you can sleep better knowing that even if you prefer COBOL, you can do almost anything those snobby C# programmers

can do. That, of course, wonâ€™t prevent them from ribbing you for being a COBOL person, butthatâ€™s another story.

Managed Modules

When you build a program with the C# compiler, the Visual Basic .NET compiler, or any other compiler capable of generating CIL, the compiler produces a managed module. A managed module issimply an executable designed to be run by the CLR. It typically, but not always, has the file nameextension EXE, DLL, or NETMODULE. Inside a managed module are four important elements:

A Windows Portable Executable (PE) file header

A CLR header containing important information about the module, such as the location of itsCIL and metadata

Metadata describing everything inside the module and its external dependencies

The CIL instructions generated from the source code

Every managed module contains metadata describing the moduleâ€™s contents. Metadata is not

optional; every CLR-compliant compiler must produce it. Thatâ€™s important, because it meansevery managed module is self-describing. Think about it this way. If someone hands you an ordinaryEXE or DLL today, can you easily crack it open and figure out what classes are inside and whatmembers those classes contain? No way! If itâ€™s a managed module, however, no problem.


18/621

Metadata is like a COM type library, but with two important differences:

Type libraries are optional; metadata is not

Metadata fully describes a module; type libraries sometimes do not

Metadata is important because the CLR must be able to determine what types are present in eachmanaged module that it loads. But itâ€™s also important to compilers and other tools that deal withmanaged executables. Thanks to metadata, Visual Studio .NET can display a context-sensitive list of the methods and properties available when you type the name of a class instance into the programeditor, a feature known as IntelliSense. And thanks to metadata, the C# compiler can look inside aDLL containing a class written in Visual Basic .NET and use it as the base class for a derived classwritten in C#.

Metadata

A moduleâ€™s core metadata is stored in a collection of tables. One table, the TypeDef table, lists allthe types defined in the module. (â€œTypeâ€• is a generic term for classes, structs, enumerations,and other forms of data understood by the CLR.) Another table lists the methods implemented bythose types, another lists the fields, another lists the properties, and so on. By reading these tables,itâ€™s possible to enumerate all the data types defined in the module as well as the members eachtype includes. Additional tables list external type references (types and type members in other modules that are used by this module), the assemblies containing the external types, and more.

Additional metadata information is stored outside the tables in heaps containing items referenced bytable entries. For example, class names and method names are stored in the string heap; string literals

are stored in a separate heap called the user-string heap. Together, metadata tables and heaps defineeverything you (or the CLR) could possibly want to know about a moduleâ€™s contents and externaldependencies.

The portion of a managed module that holds the moduleâ€™s CIL is sprinkled with metadata tokensthat refer to entries in the metadata tables. Each row in each table is identified by a 32-bit metadatatoken consisting of an 8-bit table index and a 24-bit row index. When a compiler emits the CIL for amethod, it also emits a metadata token identifying the row containing information about the method.When the CLR encounters the token, it can consult the table to discover the methodâ€™s name,visibility, signature, and even its address in memory.

The metadata format is interesting from an academic point of view, but itâ€™s rare that anapplication developer finds use for such knowledge. Most applications donâ€™t manipulate metadatadirectly; they leave that to the CLR and to compilers. Applications that need to read and writemetadata can do so by using either of two APIs provided by the .NET Framework. Called thereflection APIs, these APIs insulate the developer from the binary metadata format. One is anunmanaged API exposed through COM interfaces. The other is a managed API exposed throughclasses in the FCLâ€™s System.Reflection namespace.

Using the reflection APIs to write a tool that lists the types and type members in a managed module is

relatively easy. But if inspecting metadata is your goal, you donâ€™t have to write a tool because the.NET Framework SDK has one already. Called ILDASM, it uses reflection to reveal the contents of managed executables. Figure 1-1 shows ILDASM displaying ImageView.exe, one of the sample

programs in Chapter 4. The tree depicts the one class defined in the module (MyForm) and all the


19/621

members of that class. But hereâ€™s the cool part. If you start ILDASM with a /ADV (for â€œAdvancedâ€• ) switch and select the View/MetaInfo/Show command (or press Ctrl+M, whichworks regardless of whether you started ILDASM with a /ADV switch), a window pops up detailingall the rows in all the metadata tables (Figure 1-2). By checking and unchecking items in theView/MetaInfo menu, you can configure ILDASM to display metadata in different ways.

Figure 1-1The ILDASM view of ImageView.exe.


20/621

Figure 1-2Metadata displayed by ILDASM.

Common Intermediate Language

CIL is often described as a pseudo-assembly language because it defines a native instruction set for a

processor. In this case, however, the processor is the CLR, not a piece of silicon. You donâ€™t haveto know CIL to program the .NET Framework any more than you have to know x86 assemblylanguage to program Windows. But a rudimentary knowledge of CIL can really pay off when amethod in the FCL doesnâ€™t behave the way you expect it to and you want to know why. Youdonâ€™t have the source code for the FCL, but you do have the CIL.

In all, CIL includes about 100 different instructions. Some are the typical low-level instructions foundin silicon instruction sets, like instructions to add two values together (ADD) and to branch if twovalues are equal (BEQ). Other instructions work at a higher level and are atypical of those found inhardware instruction sets. For example, NEWOBJ instantiates an object, and THROW throws an

exception. Because the CIL instruction set is so rich, code written in high-level languages such as C#and Visual Basic .NET frequently compiles to a surprisingly small number of instructions.

CIL uses a stack-based execution model. Whereas x86 processors load values into registers tomanipulate them, the CLR loads values onto an evaluation stack. To add two numbers together, youcopy them to the stack, call ADD, and retrieve the result from the stack. Copying a value frommemory to the stack is called loading, and copying from the stack to memory is called storing. CILhas several instructions for loading and storing. LDLOC, for example, loads a value onto the stack from a memory location, and STLOC copies it from the stack to memory and removes it from thestack.

For an example of CIL at work, consider the following C# source code, which declares and initializestwo variables, adds them together, and stores the sum in a third variable:


21/621

intÂ aÂ =Â 3;intÂ bÂ =Â 7;intÂ cÂ =Â aÂ +Â b;

Hereâ€™s the CIL that Microsoftâ€™s C# compiler produces, with comments added by hand:

ldc.i4.3Â Â //Â LoadÂ aÂ 32-bitÂ (i4)Â 3Â ontoÂ theÂ stackstloc.0Â Â Â //Â StoreÂ itÂ inÂ localÂ variableÂ 0Â (a)

ldc.i4.7Â Â //Â LoadÂ aÂ 32-bitÂ (i4)Â 7Â ontoÂ theÂ stackstloc.1Â Â Â //Â StoreÂ itÂ inÂ localÂ variableÂ 1Â (b)ldloc.0Â Â Â //Â LoadÂ localÂ variableÂ 0Â ontoÂ theÂ stackldloc.1Â Â Â //Â LoadÂ localÂ variableÂ 1Â ontoÂ theÂ stackaddÂ Â Â Â Â Â Â //Â AddÂ theÂ twoÂ andÂ leaveÂ theÂ sumÂ onÂ theÂ stackstloc.2Â Â Â //Â StoreÂ theÂ sumÂ inÂ localÂ variableÂ 2Â (c)

As you can see, the CIL is pretty straightforward. Whatâ€™s not obvious, however, is how the localvariables a, b, and c (locals 0, 1, and 2 to the CLR) get allocated. The answer is through metadata.The compiler writes information into the methodâ€™s metadata noting that three local 32-bit integersare declared. The CLR retrieves the information and allocates memory for the locals before executing

the method. If you disassemble the method with ILDASM, the metadata shows up as a compiler directive:

.localsÂ initÂ (int32Â V_0,Â //Â LocalÂ variableÂ 0Â (a)Â Â Â Â Â Â Â Â Â Â Â Â Â Â int32Â V_1,Â //Â LocalÂ variableÂ 1Â (b)Â Â Â Â Â Â Â Â Â Â Â Â Â Â int32Â V_2)Â //Â LocalÂ variableÂ 2Â (c)

This is a great example of why metadata is so important to the CLR. Itâ€™s used not only to verifytype safety, but also to prepare execution contexts. Incidentally, if a C# executable is compiled with a/DEBUG switch, ILDASM will display real variable names instead of placeholders such as V_0.

The .NET Framework SDK contains a document that describes the entire CIL instruction set inexcruciating detail. I wonâ€™t clutter this chapter with a list of all the CIL instructions, but I will

provide a table that lists some of the most commonly used instructions and describes them briefly.

Common CIL InstructionsInstruction DescriptionBOX Converts a value type into a reference typeCALL Calls a method; if the method is virtual, virtualness is ignoredCALLVIRT Calls a method; if the method is virtual, virtualness is honoredCASTCLASSCasts an object to another type

LDC Loads a numeric constant onto the stack LDARG[A] Loads an argument or argument address [A] onto the stack LDELEM Loads an array element onto the stack LDLOC[A] Loads a local variable or local variable address [A] onto the stack LDSTR Loads a string literal onto the stack

NEWARR Creates a new array NEWOBJ Creates a new objectRET Returns from a method callSTARG Copies a value from the stack to an argument

STELEM Copies a value from the stack to an array elementSTLOC Transfers a value from the stack to a local variableTHROW Throws an exceptionUNBOX Converts a reference type into a value type


22/621

The same ILDASM utility that lets you view metadata is also a fine CIL disassembler. For ademonstration, start ILDASM and use it to open one of the System.*.dll DLLs in the\%SystemRoot%\Microsoft.NET\Framework\v1.0.nnnn directory. These DLLs belong to the .NETFramework class library. After opening the DLL, drill down into its namespaces and classes until youfind a method you want to disassemble. Methods are easy to spot because theyâ€™re marked withmagenta rectangles. Double-click the method and youâ€™ll see its CIL, complete with compiler

directives generated from the methodâ€™s metadata. Better still, ILDASM is a round-tripdisassembler, meaning that you can pass the disassembled code to ILASM and reproduce the CIL thatyou started with.

When speaking to groups of developers about CIL, Iâ€™m often asked about intellectual propertyissues. If you and I can disassemble the FCL, whatâ€™s to prevent a competitor from disassemblingyour companyâ€™s product? Reverse-engineering CIL isnâ€™t trivial, but itâ€™s easier thanreverse-engineeringx86 code. And decompilers that generate C# source code from CIL are freelyavailable on the Internet. So how do you protect your IP?

The short answer isâ€”it depends. Code that runs only on serversâ€”XML Web services, for exampleâ€”isnâ€™t exposed to users, so it canâ€™t be disassembled unless someone breaches your firewall. Code distributed to end users can be scrambled with third-party code obfuscation utilities.Obfuscators canâ€™t guarantee that no one can read your code, but they can make doing so harder. Inthe final analysis, someone who has physical access to your CIL and wants to reverse-engineer it

badly enough will find a way to do it. If itâ€™s any consolation, the Java community has grappledwith this problem for years. There is no perfect solution other than sticking strictly to server-sideapps.

Assemblies

You now know that compilers that target the .NET Framework produce managed modules and thatmanaged modules contain CIL and metadata. But you might be surprised to learn that the CLR isincapable of using managed modules directly. Thatâ€™s because the fundamental unit of security,versioning, and deployment in the .NET Framework is not the managed module but the assembly.

Anassembly is a collection of one or more files grouped together to form a logical unit. The termâ€œfilesâ€• in this context generally refers to managed modules, but assemblies can include filesthat are not managed modules. Most assemblies contain just one file, but assemblies can andsometimes do include multiple files. All the files that make up a multifile assembly must reside in the

same directory. When you use the C# compiler to produce a simple EXE, that EXE is not only amanaged module, itâ€™s an assembly. Most compilers are capable of producing managed modulesthat arenâ€™t assemblies and also of adding other files to the assemblies that they create. The .NETFramework SDK also includes a tool named AL (Assembly Linker) that joins files into assemblies.

Multifile assemblies are commonly used to glue together modules written in different languages andto combine managed modules with ordinary files containing JPEGs and other resources. Multifileassemblies are also used to partition applications into discrete downloadable units, which can be

beneficial for code deployed on the Internet. Imagine, for example, that someone with a dial-upconnection wants to download a multi-megabyte application housed in a single-file assembly.

Downloading the code could take forever. To mitigate the problem, you could divide the code intomultiple files and make the files part of the same assembly. Because a module isnâ€™t loaded unlessitâ€™s needed, the user wonâ€™t incur the cost of downloading the portions of the application thatarenâ€™t used. If youâ€™re smart about how you partition the code, the bulk of the application


23/621

might not have to be downloaded at all.

How does the CLR know which files belong to an assembly? One of the files in the assemblycontains a manifest. Physically, the manifest is just more metadata; when a compiler creates amanaged module that also happens to be an assembly, it simply writes the manifest into themoduleâ€™s metadata. Logically, the manifest is a road map to the assemblyâ€™s contents. Its most

important elements are

The assemblyâ€™s name

A list of the other files in the assembly, complete with cryptographic hashes of the filesâ€™contents

A list of the data types exported from other files in the assembly and information mapping thosedata types to the files in which theyâ€™re defined

A version number in the format major.minor.build.revision (for example, 1.0.3705.0)

The manifest can also include other information such as a company name, description, requestedsecurity permissions, and culture string. The latter identifies the assemblyâ€™s targeted culture (for example, â€œen-USâ€• for â€œUnited States Englishâ€• ) and is typically used with so-calledâ€œsatellite assembliesâ€• that contain only resources. Figure 1-3 depicts a multifile assembly thatconsists of three managed modules and a JPEG file. Main.exe holds the manifest, and the manifestcontains references to the other files. In the eyes of the file system, these are still separate files. But tothe CLR, theyâ€™re one logical entity.

Figure 1-3Multifile assembly.

In the absence of information directing them to do otherwise, compilers produce assemblies that areweakly named. â€œWeakly namedâ€• means that the assembly is not cryptographically signed andthat the CLR uses only the name stored in the assembly manifest (which is nothing more than the


24/621

assemblyâ€™s file name without the file name extension) to identify the assembly. But assembliescan be strongly named. A strongly named assembly contains the publisherâ€™s public key and adigital signature thatâ€™s actually a hash of the assembly manifest where the public key is stored.

The digital signature, which is generated with the publisherâ€™s private key and can be verified withthe public key, makes the assemblyâ€™s manifest (and, by extension, the assembly itself)

tamperproof. A strongly named assemblyâ€™s identity derives from the assembly name, the publickey, the version number, and the culture string, if present. Any difference, no matter how small, issufficient to distinguish two otherwise identical assemblies.

The SDKâ€™s AL utility can be used to create strongly named assemblies. Most language compilers,including the C# and Visual Basic .NET compilers, can also emit strongly named assemblies. Itâ€™sup to you whether to deploy weakly or strongly named assemblies. The right choice is dictated by theassembliesâ€™ intended use. If an assembly is to be deployed in the global assembly cache(GAC)â€”a global repository used by assemblies designed to be shared by multiple applicationsâ€”itmust be strongly named.

An assembly must also be strongly named if you want to take advantage of version checking. Whenthe CLR loads a weakly named assembly, it does no version checking. That can be good or bad.Itâ€™s good if you replace an old version of the assembly with a new one (perhaps one that hasundergone bug fixes) and want applications that use the assembly to automatically use the new one.Itâ€™s bad if youâ€™ve thoroughly tested the application against a specific version of the assemblyand someone replaces the old assembly with a new one thatâ€™s riddled with bugs. Thatâ€™s onesymptom of the DLL Hell that Windows developers are all too familiar with. Strong naming can fixthat. When the CLR loads a strongly named assembly, it compares the version number in theassembly to the version number that the application doing the loading was compiled against. (That

information, not surprisingly, is recorded in the moduleâ€™s metadata.) If the numbers donâ€™tmatch up, the CLR throws an exception.

Strict version checking, of course, has pitfalls of its own. Suppose you elect to use strong naming, butlater you find a bug in your assembly. You fix the bug and deploy the revised assembly. But guesswhat? Applications that use the assembly wonâ€™t load the new version unless you rebuild them.Theyâ€™ll still load the old version, and if you delete the old version, the applications wonâ€™t runat all. The solution is to modify the CLRâ€™s binding policy. Itâ€™s relatively simple for anadministrator to point the CLR to a new version of a strongly named assembly by editing aconfiguration file. Of course, if the newer version has bugs, youâ€™re right back to square one.

Thatâ€™s why you donâ€™t let just anyone have administrator privileges.

Working with assemblies sounds pretty complicatedâ€”and at times, it is. Fortunately, if youâ€™renot building shared assemblies or assemblies that link to other assemblies (other than the FCL, which,

by the way, is a set of shared assemblies), most of the issues surrounding naming and binding fall bythe wayside. You just run your compiler, copy the resulting assembly to a directory, and run it.Couldnâ€™t be much simpler than that.

The .NET Framework Class Library

Windows programmers who code in C tend to rely on the Windows API and functions in third-partyDLLs to get their job done. C++ programmers often use class libraries of their own creation or standard class libraries such as MFC. Visual Basic programmers use the Visual Basic API, which isan abstraction of the underlying operating system API.


25/621

Using the .NET Framework means you can forget about all these anachronistic APIs. You have a brand new API to learn, that of the .NET Framework class library, which is a library of more than7,000 typesâ€”classes, structs, interfaces, enumerations, and delegates (type-safe wrappers aroundcallback functions)â€”that are an integral part of the .NET Framework. Some FCL classes containupward of 100 methods, properties, and other members, so learning the FCL isnâ€™t a chore to betaken lightly. The bad news is that itâ€™s like learning a brand new operating system. The good

news is that every language uses the same API, so if your company decides to switch from VisualBasic to C++ or vice versa, the investment you make in learning the FCL isnâ€™t lost.

To make learning and using the FCL more manageable, Microsoft divided the FCL into hierarchicalnamespaces. The FCL has about 100 namespaces in all. Each namespace holds classes and other types that share a common purpose. For example, much of the window manager portion of theWindows API is encapsulated in the System.Windows.Forms namespace. In that namespaceyouâ€™ll find classes that represent windows, dialog boxes, menus, and other elements commonlyused in GUI applications. A separate namespace called System.Collections holds classes representinghash tables, resizable arrays, and other data containers. Yet another namespace, System.IO, contains

classes for doing file I/O. Youâ€™ll find a list of all the namespaces present in the FCL in the .NETFramework SDKâ€™s online documentation. Your job as a budding .NET programmer is to learnabout those namespaces. Fortunately, the FCL is so vast and so comprehensive that most developerswill never have to tackle it all.

The following table lists a few of the FCLâ€™s namespaces and briefly describes their contents. Theterm â€œet alâ€• refers to a namespaceâ€™s descendants. For example, System.Data et al refers toSystem.Data,System.Data.Common,System.Data.OleDb,System.Data.SqlClient, andSystem.Data.SqlTypes.

A Sampling of FCL Namespaces Namespace ContentsSystem Core data types and auxiliary classesSystem.Collections Hash tables, resizable arrays, and other containersSystem.Data et al ADO.NET data access classesSystem.Drawing Classes for generating graphical output (GDI+)System.IO Classes for performing file and stream I/OSystem.Net Classes that wrap network protocols such as HTTPSystem.Reflection et al Classes for reading and writing metadataSystem.Runtime.Remoting et alClasses for writing distributed applications

System.ServiceProcess Classes for writing Windows servicesSystem.Threading Classes for creating and managing threadsSystem.Web HTTP support classesSystem.Web.Services Classes for writing Web servicesSystem.Web.Services.ProtocolsClasses for writing Web service clientsSystem.Web.UI Core classes used by ASP.NETSystem.Web.UI.WebControls ASP.NET server controlsSystem.Windows.Forms Classes for GUI applicationsSystem.Xml et al Classes for reading and writing XML data

The first and most important namespace in the FCLâ€”the one that every application usesâ€”isSystem. Among other things, the System namespace defines the core data types employed bymanaged applications: bytes, integers, strings, and so on. When you declare an int in C#, youâ€™re


26/621

actually declaring an instance of System.Int32. The C# compiler recognizes int as a shortcut simply because itâ€™s easier to write

intÂ aÂ =Â 7;

than it is to write

System.Int32Â aÂ =Â 7;

TheSystem namespace is also home for many of the exception types defined in the FCL (for example,InvalidCastException) and for useful classes such as Math, which contains methods for

performing complex mathematical operations; Random, which implements a pseudo-random number generator; and GC, which provides a programmatic interface to the garbage collector.

Physically, the FCL is housed in a set of DLLs in the\%SystemRoot%\Microsoft.NET\Framework\v1.0.nnnn directory. Each DLL is an assembly that can

be loaded on demand by the CLR. Core data types such as Int32 are implemented in Mscorlib.dll;other types are spread among the FCL DLLs. The documentation for each type lists the assembly inwhich itâ€™s defined. Thatâ€™s important, because if a compiler complains about an FCL class

being an undefined type, you must point the compiler to the specific assembly that implements theclass for you. The C# compiler uses /r [eference] switches to identify referenced assemblies.

Obviously, no one chapter (or even one book) can hope to cover the FCL in its entirety. Youâ€™ll become acquainted with many FCL classes as you work your way through this book. Chapter 3 kicksthings off by introducing some of the FCLâ€™s coolest classes and namespaces. For now, realize thatthe FCL is the .NET Framework API and that itâ€™s an extraordinarily comprehensive class library.The more you use it, the more youâ€™ll like it, and the more youâ€™ll come to appreciate the sheer

effort that went into putting it together.


27/621

Your First .NET Framework Application

If the information presented thus far in Chapter 1 seems hopelessly abstract, take heart: things are aboutto get concrete very quickly. Itâ€™s time to develop your first .NET Framework application. And what

better way to start than by writing a managed version of â€œHello, worldâ€• ? To keep it simple,weâ€™ll write a console applicationâ€”one that runs in a command prompt window. That will keep the

code as uncluttered as possible and allow us to focus on the issues that matter most.

Hello, World

Figure 1-4 lists the contents of Hello.cs, a C# source code file containing the .NET Framework versionof â€œHello, world.â€• To compile it, open a command prompt window, go to the directory whereHello.cs is stored, and type the following command:

cscÂ /target:exeÂ /out:Hello.exeÂ Hello.cs

This command invokes the C# compiler and produces an executable named Hello.exe. The /target

switch, which can be abbreviated /t, tells the compiler to produce a console application. Because aconsole application is the default, and because the default EXE file name is the name of the CS file, youcan save wear and tear on your fingers by compiling the program with the command

cscÂ Hello.cs

Once the compilation process is complete, run Hello.exe by typing helloat the command prompt.â€œHello, worldâ€• should appear in the window, as shown in Figure 1-5.

Hello.csusingÂ System;

classÂ MyApp{

Â Â Â Â staticÂ voidÂ MainÂ ()Â Â Â Â {

Â Â Â Â Â Â Â Â Console.WriteLineÂ ("Hello,Â world");Â Â Â Â }

}

Figure 1-4â€œHello, worldâ€• in C#.


28/621

Figure 1-5Output from Hello.exe.

So what happened when you ran Hello.exe? First, a short x86 stub emitted by the compiler transferredcontrol to the CLR. The CLR, in turn, located and called the programâ€™s Main method, whichcompiled to three simple CIL instructions. The JIT compiler transformed the instructions into x86machine code and executed them. Had you compiled and run the EXE on another type of machine, thesame CIL instructions would have compiled to instructions native to the host processor.

Inside Hello.cs

Letâ€™s talk about the code in Figure 1-4. For starters, every application has to have an entry point. For a C# application, the entry point is a static method named Main. Every C# application has one. BecauseC# requires that all methods belong to a type, in Hello.cs, Main is a member of MyApp. Thereâ€™snothing magic about the class name; you could name it Foo and it would work just the same. If anapplication contains multiple classes and multiple Main methods, a /main switch tells the C# compiler which class contains the Main method thatâ€™s the entry point.

The one and only statement in MyApp.Main is the one that writes â€œHello, worldâ€• to the console

window. If Hello were a standard Windows application written in C or C++, youâ€™d probably use printf to write the output. But this isnâ€™t a standard Windows application. Itâ€™s a .NET Framework application, and .NET Framework applications use the FCL to write to console windows. The FCLâ€™sSystem namespace features a class named Console that represents console windows. Look up Console inthe FCL reference, and youâ€™ll find that it contains a static method named WriteLine that writes a lineof text to the window (or to wherever standard output happens to point at the time).

The statement

usingÂ System;

at the beginning of the program is a syntactical simplification. Remember that the FCL contains morethan 7,000 members divided into approximately 100 namespaces. Without the using directive, youâ€™dhave to qualify the reference to Console by prefacing the class name with the namespace name, as


29/621

shown here:

System.Console.WriteLineÂ ("Hello,Â world");

But with the using directive, you can abbreviate the reference by specifying only the class name. Itâ€™snot a big deal here, but when you write programs containing hundreds, perhaps thousands, of referencesto FCL classes, youâ€™ll appreciate not having to type the namespace names over and over. Most

languages support the using directive or an equivalent. In Visual Basic .NET, itâ€™s called Imports.

What happens if two namespaces contain identically named classes and you use both of those classes inyour application? Simple: you have to qualify the references one way or another. The following codewonâ€™t compile because both namespaces contain classes named ListBox:

usingÂ System.Windows.Forms;usingÂ System.Web.UI.WebControls;

ListBoxÂ winLBÂ =Â newÂ ListBoxÂ ();Â //Â CreateÂ aÂ WindowsÂ FormsÂ ListBox

ListBoxÂ webLBÂ =Â newÂ ListBoxÂ ();Â //Â CreateÂ aÂ WebÂ FormsÂ ListBox

Consequently, you have two choices. The first is to fully qualify the class names:

System.Windows.Forms.ListBoxÂ winLBÂ =newÂ System.Windows.Forms.ListBoxÂ ();System.Web.UI.WebControls.ListBoxÂ webLBÂ =Â Â Â Â newÂ System.Web.UI.WebControls.ListBoxÂ ();

The second is to use an alternative form of the using directive to create aliases for the fully qualifiedclass names:

usingÂ winListBoxÂ =Â System.Windows.Forms.ListBox;

usingÂ webListBoxÂ =Â System.Web.UI.WebControls.ListBox;

winListBoxÂ winLBÂ =Â newÂ winListBoxÂ ();Â //Â CreateÂ aÂ WindowsÂ FormsÂ ListBowebListBoxÂ webLBÂ =Â newÂ webListBoxÂ ();Â //Â CreateÂ aÂ WebÂ FormsÂ ListBox

This example is admittedly contrived because youâ€™ll probably never use a Web Forms ListBox and aWindows Forms ListBox in the same program (not for any reason I can think of, anyway). But the

principle is valid just the same.

More About the Main Method

Helloâ€™sMain method accepts no parameters and returns no data, but thatâ€™s just one of four different ways that you can prototype Main. All of the following are legitimate:

staticÂ voidÂ MainÂ ()staticÂ intÂ MainÂ ()staticÂ voidÂ MainÂ (string[]Â args)staticÂ intÂ MainÂ (string[]Â args)

Theargs parameter is an array of strings containing the programâ€™s command-line arguments. Thestring at index 0 is the first argument, the string at index 1 is the second, and so on. If you rewrote the

program this way:usingÂ System;

classÂ MyApp


30/621

{

Â Â Â Â staticÂ voidÂ MainÂ (string[]Â args)Â Â Â Â {

Â Â Â Â Â Â Â Â Console.WriteLineÂ ("Hello, " +Â args[0]);Â Â Â Â }

}

and started it by typing hello .NET, the output from the program would be â€œHello, .NET.â€• Use theform of Main that receives an args parameter if you want to accept command-line input in your program.

The modified form of Hello.cs in the previous paragraph has one little problem: if you run it without anycommand-line parameters, it throws an exception because the 0 in args[0] constitutes an invalid arrayindex. To find out how many command-line parameters were entered, read the string arrayâ€™s Length

property, as in:

intÂ countÂ =Â args.Length;

This statement works because an array in the framework is an instance of System.Array, and

System.Array defines a property named Length. You can use Length to determine the number of itemsin any array, no matter what type of data the array stores.

Inside Hello.exe

If youâ€™d like to see Hello.exe as the CLR sees it, start ILDASM and open Hello.exe. Youâ€™ll seethe window shown in Figure 1-6. The first red triangle represents the assembly manifest. Double-click it, and youâ€™ll see a list of assemblies that this assembly depends on (â€œ.assembly externmscorlibâ€• ), as shown in Figure 1-7. Youâ€™ll also see the assembly name (â€œ.assembly Helloâ€• )and a list of the modules that make up the assembly. Because Hello.exe is a single-file assembly, itâ€™s

the only module that appears in the list.

Figure 1-6ILDASM displaying the contents of Hello.exe.


31/621

Figure 1-7Hello.exeâ€™s manifest.

ILDASM also reveals that Hello.exe contains a class named MyApp and that MyApp contains twomethods: a constructor (.ctor ) and Main. The constructor was generated automatically by the compiler;

itâ€™s a default constructor that takes no arguments. The â€œSâ€• in the box next to Main indicatesthatMain is a static method. Double-clicking Main displays the CIL generated for that method by theC# compiler. (See Figure 1-8.) The statement

.entrypoint

isnâ€™t CIL but is simply a directive noting that this method is the programâ€™s entry point. The entry pointâ€™s identity came from Hello.exeâ€™s CLR header. Next, the statement

.maxstackÂ 1

is information obtained from the method prologueâ€”data bytes preceding the method in theCILâ€”indicating that this method requires no more than one slot in the CLRâ€™s evaluation stack. TheCLR uses this information to size the evaluation stack prior to invoking the method.

Mainâ€™s CIL consists of just three simple instructions:

A LDSTR instruction that places â€œHello, worldâ€• on the evaluation stack

A CALL instruction that calls System.Consoleâ€™sWriteLine method in Mscorlib

A RET instruction that ends the method

As you can see, itâ€™s relatively easy to use ILDASM to figure out how a method works. Early .NETFramework developers spent copious amounts of time figuring out how the FCL works by poring over the CIL for individual methods.


32/621

Figure 1-8TheMain method disassembled.


33/621

The Big Picture

Hello.exe is a far cry from a full-blown Web service or an eBay-style Web app, but itâ€™s animportant beginning. Why? Because at the CLR level, all applications are created equal. Onceyou know how to write code that leverages the CLR, learning to write GUI applications, Webapplications, and other .NET Framework application types is simply a matter of learning the

programming models and getting to know your way around the FCLâ€”which is precisely whatthe remainder of this book is about.

To summarize what youâ€™ve learned so far: the .NET Framework is a platform for Webservices and other kinds of applications. Applications that target the .NET Framework aremanaged applications. Theyâ€™re made of CIL and metadata, and theyâ€™re JIT compiled atrun time and executed by the CLR. Languages such as C# and Visual Basic .NET are syntactictools for generating CIL. For the first time in programming history, language is unimportant

because, at the end of the day, all languages exercise the same set of features in the CLR andFCL.

Ironically, the .NET Framework grew out of an effort by a lot of smart people at Microsoft tomake COM programming easier. Little did they know that the solution theyâ€™d come up withwasnâ€™t to fix what was broken, but to tear it down and start over again. Thatâ€™s what the.NET Framework is: a new beginning. The sooner you can let go of the old ways of writing andexecuting code, the more quickly youâ€™ll adapt to the .NET way.


34/621

Chapter 2Types and Exceptions

Before you begin drilling down into the Microsoft .NET Framework class library (FCL) and thevarious programming models that it supports, itâ€™s helpful to understand what the FCL ismade of. The FCL is a library of â€œtypes,â€• which is a generic way of referring to classes,

structs, interfaces, enumerations, and delegates. This chapter defines these terms and will makeChapter 3 more meaningful to developers who are new to the .NET Framework. This chapter also introduces some potential pitfalls related to types, including common errors that arise whenusing types that encapsulate file handles and other resources that arenâ€™t managed by thegarbage collector.

Understanding the .NET Frameworkâ€™s type system and the differences between the variouskinds of data types that it supports is important, but so is understanding how types are loaded,versioned, and deployed. Types are packaged in assemblies. The FCL is a set of many differentassemblies, each one of them shared so that any application can use it. Applications, too, are

deployed as assemblies. You already know that an assembly is a group of one or more files. Youeven created a single-file assembly (Hello.exe) in Chapter 1. What you donâ€™tknowâ€”yetâ€”is how to create assemblies of your own that contain types that can be used byother programs. Youâ€™ll remedy that in this chapter by building and deploying a multifile,multilanguage assembly, and then building a client that dynamically links to it. In addition togaining valuable insight into how the FCL works, youâ€™ll see what it takes to build classlibraries of your own and learn how to use the assembly-based versioning mechanism in thecommon language runtime (CLR) to avoid DLL Hellâ€”the term used to describe what happenswhen a fix made to a DLL for the benefit of one application breaks another application (or

perhaps breaks the very application that the fix was intended to help).

Finally, youâ€™ll learn about exception handling. Applications that use the .NET Framework employ a C++-like try/catch mechanism to achieve robustness without having to check the returnvalue from each and every method call. In fact, checking return values does little good becausethe CLR and FCL donâ€™t flag errors by returning error codes; they throw exceptions. Aworking knowledge of how exception handling works and how languages such as C# expose theCLRâ€™s exception handling mechanism is essential to becoming a proficient .NET Framework

programmer.


35/621

.NET Framework Data Types

The C in FCL stands for â€œclass,â€• but the FCL isnâ€™t strictly a class library; itâ€™s a library of typesfollowing:

Classes

Structs

Interfaces

Enumerations

Delegates

Understanding what a type is and how one type differs from another is crucial to understanding the FCL. Thesections will not only enrich your understanding of the FCL, but also help you when the time comes to build

Classes

A class in the .NET Framework is similar to a class in C++: a bundle of code and data that is instantiated to fobject-oriented programming languages such as C++ contain member variables and member functions. Framcontain the following members:

Fields, which are analogous to member variables in C++

Methods, which are analogous to member functions in C++

Properties, which expose data in the same way fields do but are in fact implemented using accessor (get

Events, which define the notifications a class is capable of firing

Here, in C#, is a class that implements a Rectangle data type:

classÂ Rectangle{

Â Â Â Â //Â FieldsÂ Â Â Â protectedÂ intÂ widthÂ =Â 1;Â Â Â Â protectedÂ intÂ heightÂ =Â 1;

Â Â Â Â //Â PropertiesÂ Â Â Â publicÂ intÂ WidthÂ Â Â Â {

Â Â Â Â Â Â Â Â getÂ {Â returnÂ width;Â }Â Â Â Â Â Â Â Â setÂ Â Â Â Â Â Â Â {Â Â Â Â Â Â Â Â Â Â Â Â ifÂ (valueÂ >Â 0)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â widthÂ =Â value;Â Â Â Â Â Â Â Â Â Â Â Â elseÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â throwÂ newÂ ArgumentOutOfRangeExceptionÂ (Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "WidthÂ mustÂ beÂ 1Â orÂ higher");

Â Â Â Â Â Â Â Â }Â Â Â Â }

Â Â Â Â publicÂ intÂ HeightÂ Â Â Â {


36/621

Â Â Â Â Â Â Â Â getÂ {Â returnÂ height;Â }Â Â Â Â Â Â Â Â setÂ Â Â Â Â Â Â Â {Â Â Â Â Â Â Â Â Â Â Â Â ifÂ (valueÂ >Â 0)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â heightÂ =Â value;Â Â Â Â Â Â Â Â Â Â Â Â elseÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â throwÂ newÂ ArgumentOutOfRangeExceptionÂ (Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "HeightÂ mustÂ beÂ 1Â orÂ higher");

Â Â Â Â Â Â Â Â }Â Â Â Â }

Â Â Â Â publicÂ intÂ AreaÂ Â Â Â {

Â Â Â Â Â Â Â Â getÂ {Â returnÂ widthÂ *Â height;Â }Â Â Â Â }

Â Â Â Â //Â MethodsÂ (constructors)Â Â Â Â publicÂ RectangleÂ ()Â {}Â Â Â Â publicÂ RectangleÂ (intÂ cx,Â intÂ cy)Â Â Â Â {

Â Â Â Â Â Â Â Â WidthÂ =Â cx;Â Â Â Â Â Â Â Â HeightÂ =Â cy;Â Â Â Â }

}

Rectangle has seven class members: two fields, three properties, and two methods, which both happen to bethat are called each time an instance of the class is created. The fields are protected, which means that only Rderivatives can access them. To read or write a Rectangleobjectâ€™s width and height, a client must use the

Notice that these propertiesâ€™ set accessors throw an exception if an illegal value is entered, a protection tRectangleâ€™s width and height been exposed through publicly declared fields. Area is a read-only propertycompiler will flag attempts to write to the Area property with compilation errors.

Many languages that target the .NET Framework feature a new operator for instantiating objects. The followiRectangle in C#:

RectangleÂ rectÂ =Â newÂ RectangleÂ ();Â Â Â Â Â //Â UseÂ firstÂ constructorRectangleÂ rectÂ =Â newÂ RectangleÂ (3,Â 4);Â //Â UseÂ secondÂ constructor

Once the object is created, it might be used like this:

rect.WidthÂ *=Â 2;Â Â Â Â Â Â //Â DoubleÂ theÂ rectangle'sÂ widthintÂ areaÂ =Â rect.Area;Â //Â GetÂ theÂ rectangle'sÂ newÂ area

Significantly, neither C# nor any other .NET programming language has a delete operator. You create objectsthem.

In C#, classes define reference types, which are allocated on the garbage-collected heap (which is often calleitâ€™s managed by the garbage collector) and accessed through references that abstract underlying pointers.type is the value type, which youâ€™ll learn about in the next section. Most of the time you donâ€™t have tdifferences between the two, but occasionally the differences become very important and can actually be debaccounted for. See the section â€œBoxing and Unboxingâ€• later in this chapter for details.

All classes inherit a virtual method named Finalize from System.Object, which is the ultimate root class for a

just before an object is destroyed by the garbage collector. The garbage collector frees the objectâ€™s memohandles, window handles, and other unmanaged resources (â€œunmanagedâ€• because theyâ€™re not freedoverrideFinalize and use it to free those resources. This, too, has some important implications for developerschapter in the section entitled â€œNondeterministic Destruction.â€•


37/621

Incidentally, classes can derive from at most one other class, but they can derive from one class and any numthe documentation for FCL classes, donâ€™t be surprised if you occasionally see long lists of base â€œclassclasses at all, but interfaces. Also be aware that if you donâ€™t specify a base class when declaring a class, ySystem.Object. Consequently, you can call ToString and other System.Object methods on any object.

Structs

Classes are intended to represent complex data types. Because class instances are allocated on the managed hwith creating and destroying them. Some types, however, are â€œsimpleâ€• types that would benefit from blives outside the purview of the garbage collector and offers a high-performance alternative to the managed hexamples of simple data types.

Thatâ€™s why the .NET Framework supports value types as well as reference types. In C#, value types are dValue types impose less overhead than reference types because theyâ€™re allocated on the stack, not the heaother â€œprimitiveâ€• data types that the CLR supports are value types.

Hereâ€™s an example of a simple value type:structÂ Point{

Â Â Â Â publicÂ intÂ x;Â Â Â Â publicÂ intÂ y;Â Â Â Â publicÂ PointÂ (intÂ x,Â intÂ y)Â Â Â Â {

Â Â Â Â Â Â Â Â this.xÂ =Â x;Â Â Â Â Â Â Â Â this.yÂ =Â y;Â Â Â Â }

}

Point stores x and y coordinates in fields exposed directly to clients. It also defines a constructor that can bePoint in one operation. A Point can be instantiated in any of the following ways:

PointÂ pointÂ =Â newÂ PointÂ (3,Â 4);Â //Â x==3,Â y==4PointÂ pointÂ =Â newÂ PointÂ ();Â Â Â Â Â //Â x==0,Â y==0PointÂ point;Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â //Â x==0,Â y==0

Note that even though the first two statements appear to create a Point object on the heap, in reality the objeccome from a C++ heritage, get over the notion that new always allocates memory on the heap. Also, despite tcreates a Point object whose fields hold zeros, C# considers the Point to be uninitialized and wonâ€™t let yo

values to x and y.Value types are subject to some restrictions that reference types are not. Value types canâ€™t derive from otderive from System.ValueType and can (and often do) derive from interfaces. They also shouldnâ€™t wraphandles because value types have no way to release those resources when theyâ€™re destroyed. Even thoughmethod from System.Object,Finalize is never called because the garbage collector ignores objects created on

Interfaces

An interface is a group of zero or more abstract methodsâ€”methods that have no default implementation butclass or struct. Interfaces can also include properties and events, although methods are far more common.

An interface defines a contract between a type and users of that type. For example, many of the classes in thederive from an interface named IEnumerable.IEnumerable defines methods for iterating over the items in a cFCLâ€™s collection classes implement IEnumerable that C#â€™s foreach keyword can be used with them.


38/621

fromforeach uses IEnumerableâ€™sGetEnumerator method to iterate over the collectionâ€™s contents.

Interfaces are defined with C#â€™s interface keyword:

interfaceÂ ISecret{

Â Â Â Â voidÂ EncryptÂ (byte[]Â inbuf,Â outÂ byte[]Â outbuf,Â KeyÂ key);Â Â Â Â voidÂ UnencryptÂ (byte[]Â inbuf,Â outÂ byte[]Â outbuf,Â KeyÂ key);}

A class or struct that wants to implement an interface simply derives from it and provides concrete implemen

classÂ MessageÂ :Â ISecret{

Â Â Â Â publicÂ voidÂ EncryptÂ (byte[]Â inbuf,Â outÂ byte[]Â outbuf,Â KeyÂ key)Â Â Â Â {

Â Â Â Â Â Â ...

Â Â Â Â }

Â Â Â Â publicÂ voidÂ UnencryptÂ (byte[]Â inbuf,Â outÂ byte[]Â outbuf,Â KeyÂ key)

Â Â Â Â {Â Â Â Â Â Â ...

Â Â Â Â }

}

In C#, the is keyword can be used to determine whether an object implements a given interface. If msg is anthen in this example, is returns true; otherwise, it returns false:

ifÂ (msgÂ isÂ ISecret)Â {Â Â Â Â ISecretÂ secretÂ =Â (ISecret)Â msg;Â Â Â Â secret.EncryptÂ (...);}

The related as operator can be used to test an object for an interface and cast it to the interface type with a sin

Enumerations

Enumerations in .NET Frameworkâ€“land are similar to enumerations in C++. Theyâ€™re types that consistin C# theyâ€™re defined with the enum keyword. Hereâ€™s a simple enumerated type named Color :

enumÂ Color{

Â Â Â Â Red,

Â Â Â Â Green,Â Â Â Â Blue}

WithColor thusly defined, colors can be represented this way:

Color.RedÂ Â Â Â //Â RedColor.GreenÂ Â //Â GreenColor.BlueÂ Â Â //Â Blue

Many FCL classes use enumerated types as method parameters. For example, if you use the Regex class to p be case-insensitive, you donâ€™t pass a numeric value to Regexâ€™s constructor; you pass a member of anRegexOptions:

RegexÂ regexÂ =Â newÂ RegexÂ (exp,Â RegexOptions.IgnoreCase);


39/621

Using words rather than numbers makes your code more readable. Nevertheless, because an enumerated typenumeric values (by default, 0 for the first member, 1 for the second, and so on), you can always use a number

prefer.

Theenum keyword isnâ€™t simply a compiler keyword; it creates a bona fide type that implicitly derives frodefines methods that you can use to do some interesting things with enumerated types. For example, you can

type to enumerate the names of all its members. Try that in unmanaged C++!Delegates

Newcomers to the .NET Framework often find delegates confusing. A delegate is a type-safe wrapper aroundrather simple to write an unmanaged C++ application that crashes when it performs a callback. Itâ€™s impoapplication that does the same, thanks to delegates.

Delegates are most commonly used to define the signatures of callback methods that are used to respond to eTimer class (a member of the System.Timers namespace) defines an event named Elapsed that fires wheneveelapses. Applications that want to respond to Elapsed events pass a Timer object a reference to the method th

event fires. The â€œreferenceâ€• that they pass isnâ€™t a raw memory address but rather an instance of a dmethodâ€™s memory address. The System.Timers namespace defines a delegate named ElapsedEventHandl

If you could steal a look at the Timerclassâ€™s source code, youâ€™d see something like this:

publicÂ delegateÂ voidÂ ElapsedEventHandlerÂ (ObjectÂ sender,Â ElapsedEventArgsÂ

publicÂ classÂ Timer{

Â Â Â Â publicÂ eventÂ ElapsedEventHandlerÂ Elapsed;Â Â Â Â Â Â .Â Â Â Â Â Â .

Â Â Â Â Â Â .}

Hereâ€™s how Timer fires an Elapsed event:

ifÂ (ElapsedÂ !=Â null)Â //Â MakeÂ sureÂ somebody'sÂ listeningÂ Â Â Â ElapsedÂ (this,Â newÂ ElapsedEventArgsÂ (...));Â //Â Fire!

And hereâ€™s how a client might use a Timer object to call a method named UpdateData every 60 seconds:

TimerÂ timerÂ =Â newÂ TimerÂ (60000);timer.ElapsedÂ +=Â newÂ ElapsedEventHandlerÂ (UpdateData);

Â Â .Â Â .Â Â .voidÂ UpdateDataÂ (ObjectÂ sender,Â ElapsedEventArgsÂ e){

Â Â Â Â //Â CallbackÂ received!}

As you can see, UpdateData conforms to the signature specified by the delegate. To register to receive Elapseinstance of ElapsedEventHandler that wraps UpdateData (note the reference to UpdateData passed to Elapseand wires it to timer â€™sElapsed event using the += operator. This paradigm is used over and over in .NET

and delegates are an important feature of the type system.

In practice, itâ€™s instructive to know more about what happens under the hood when a compiler encounter the C# compiler encounters code such as this:

8/17/2019 Programming

programming microsoft .net

Documents