Summary C# and the .NET Platform, Second Edition
by Andrew Troelsen ISBN:1590590554
The purpose of this chapter was to round out your understanding of the C# programming language. We
Apress © 2003 (1200 pages)
began by examining a small set of lesser know keywords (e.g., "sizeof", "checked", "unsafe", and so forth)
This comprehensive text starts with a brief overview of the and during the processC# languagecameandto learnthenhowquicklyto workmoveswitho rawkey technicalpointer typesand .
architectural issues for .NET developers.
The remainder of this chapter was spent investigating various advanced type construction techniques (indexer methods, overloaded operators, and custom conversion routines). As you have seen, each of
TabletheseofconstrucContents can be triggered from languages other than C# (directly or indirectly).
C# and the .NET Platform, Second Edition
Introduction
Part One - Introducing C# and the .NET Platform
Chapter 1 - The Philosophy of .NET
Chapter 2 - Building C# Applications
Part Two - The C# Programming Language
Chapter 3 - C# Language Fundamentals
Chapter 4 - Object-Oriented Programming with C#
Chapter 5 - Exceptions and Object Lifetime
Chapter 6 - Interfaces and Collections
Chapter 7 - Callback Interfaces, Delegates, and Events
Chapter 8 - Advanced C# Type Construction Techniques
Part Three - Programming with .NET Assemblies
Chapter 9 - Understanding .NET Assemblies
Chapter 10 - Processes, AppDomains, Contexts, and Threads
Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming
Part Four - Leveraging the .NET Libraries
Chapter 12 - Object Serialization and the .NET Remoting Layer
Chapter 13 - Building a Better Window (Introducing Windows Forms)
Chapter 14 - A Better Painting Framework (GDI+)
Chapter 15 - Programming with Windows Forms Controls
Chapter 16 - The System.IO Namespace
Chapter 17 - Data Access with ADO.NET
Part Five - Web Applications and XML Web Services
Chapter 18 - ASP.NET Web Pages and Web Controls
Chapter 19 - ASP.NET Web Applications
Chapter 20 - XML Web Services
Index
List of Figures
List of Tables
Part Three:C# andProgrammingthe .NET Platfor , SecondwithEdition.NET Assemblies
by Andrew Troelsen |
ISBN:1590590554 |
Apress © 2003 (1200 pages)
Chapter ListThis comprehensive text starts with a brief overview of the C# language and then quickly moves to key technical and architectural issues for .NET developers.
Chapter 9: Understanding .NET Assemblies
Table of Contents
Chapter 10: Processes, AppDomains, Contexts, and Threads
C# and the .NET Platform, Second Edition
Introduction
Chapter 11: Type Reflection, Late Binding, and Attribute-Based Programming
Part One - Introducing C# and the .NET Platform
Chapter 1 - The Philosophy of .NET
Chapter 2 - Building C# Applications
Part Two - The C# Programming Language
Chapter 3 - C# Language Fundamentals
Chapter 4 - Object-Oriented Programming with C#
Chapter 5 - Exceptions and Object Lifetime
Chapter 6 - Interfaces and Collections
Chapter 7 - Callback Interfaces, Delegates, and Events
Chapter 8 - Advanced C# Type Construction Techniques
Part Three - Programming with .NET Assemblies
Chapter 9 - Understanding .NET Assemblies
Chapter 10 - Processes, AppDomains, Contexts, and Threads
Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming
Part Four - Leveraging the .NET Libraries
Chapter 12 - Object Serialization and the .NET Remoting Layer
Chapter 13 - Building a Better Window (Introducing Windows Forms)
Chapter 14 - A Better Painting Framework (GDI+)
Chapter 15 - Programming with Windows Forms Controls
Chapter 16 - The System.IO Namespace
Chapter 17 - Data Access with ADO.NET
Part Five - Web Applications and XML Web Services
Chapter 18 - ASP.NET Web Pages and Web Controls
Chapter 19 - ASP.NET Web Applications
Chapter 20 - XML Web Services
Index
List of Figures
List of Tables
Chapter C#9:andUnderstandingthe .NET Platform, Second.NETEdition Assemblies
by Andrew Troelsen ISBN:1590590554
Apress © 2003 (1200 pages)
Each of the applications developed in the first eight chapters are along the lines of traditional "stand-alone"
This comprehensive text starts withcontaineda bri f overview of the
applications, given that all programming logic is within a single *.exe. One major aspect of .NET
C# language and then quickly moves to key technical and
is the notion of binary reuse. Like COM, .NET provides the ability to access types located in external architectural issues for .NET developers.
binaries in a language-independent manner. However, the .NET platform provides far greater language integration than classic COM. For example, the .NET platform supports cross-language inheritance (e.g.,
a Visual Basic .NET class deriving from a C# class). To understand how this is achieved requires a deeper
Table of Contents
understanding of assemblies.
C# and the .NET Platform, Second Edition
Introduction
Once you understand the logical and physical layout of an assembly, you then learn the distinction
Part One - Introducing C# and the .NET Platform
between "private" and "shared" assemblies, as well as single file and multifile assemblies. You also
Chapter 1 - The Philosophy of .NET
examine exactly how the .NET runtime resolves the location of an assembly and come to understand the
Chapter 2 - Building C# Applications
role of the Global Assembly Cache (GAC) and application configuration files (*.config). As you will see, Part*.configTwo -filesThemayC# Programmingbe used by aLanguageclient application to interact with the assembly binding process.
Chapter 3 - C# Language Fundamentals
Chapter 4 - Object-Oriented Programming with C#
Problems with Classic COM Binaries
Chapter 5 - Exceptions and Object Lifetime
ChapterBinary reuse6 - Interfaces(i. ., portablend Collectionscode libraries) is not a new idea. To date, the most popular way in which a
Chapterprogrammer7 - Callbackcan shareInterfaces,types betweenDel gates,binariesnd Eve(antsd in some respects, across languages) is to build what
Chcanpternow8 be- Advregardednc C#as "classicType ConstructionCOM serversTechniques." Although the construction and use of COM binaries is a
PartwellThree-established- Programmingindustrywithstandard,.NET Assembliesthese little blobs have caused each of us a fair share of headaches. ChapterBeyond9the- factUnderstandingthat COM .demandsNET Assembliesa good deal of complex infrastructure (IDL, class factories, scripting
support, and so forth), I am sure you have also pondered the following questions during your time
Cha ter 10 - Processes, AppDomains, Contexts, and Threads
developing with COM:
Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming
Part Four - Leveraging the .NET Libraries
Why is it so difficult to version my COM binary?
Chapter 12 - Object Serialization and the .NET Remoting Layer
Chapter 13 - Building a Better Window (Introducing Windows Forms)
Why is it so complex to distribute my COM binary?
Chapter 14 - A Better Painting Framework (GDI+)
The .NET Framework greatly improves on the current state of affairs and addresses the versioning and
Chapter 15 - Programming with Windows Forms Controls
deployment problems head-on using a new binary format termed an assembly. However, before you
Chapter 16 - The System.IO Namespace
come to understand how the assembly offers a clean solution to these issues, let's spend some time
Chapter 17 - Data Access with ADO.NET
recapping the problems in a bit more detail.
Part Five - Web Applications and XML Web Services
Chapter 18 - ASP.NET Web Pages and Web Controls
ChapterProblem:19 - ASPCOM.NET WebVersioningApplicatio s
Chapter 20 - XML Web Services
In COM, you build entities named coclasses that are little more than a custom UDT (user-defined type)
Index
implementing any number of COM interfaces (including the mandatory IUnknown). The coclasses are
List of Figures
then packaged into a binary home, which is physically represented as a *.dll or *.exe file. Once all the
List of Tables
(known) bugs have been squashed out of the code, the COM binary eventually ends up on some user's computer, ready to be accessed by other programs.
The versioning problem in COM revolves around the fact that the COM runtime offers no intrinsic support to ensure that the correct version of a binary server is loaded for the calling client. It is true that a COM programmer can modify the version of the type library, update the registry to reflect these changes, and even reengineer the client's code base to reference a particular library. But, the fact remains that these are tasks delegated to the programmer and typically require rebuilding the code base and redeploying the software. As many of you have learned the hard way, this is far from ideal.
Assume that you have jumped through the necessary hoops to try to ensure the COM client activates the correct version of a COM binary. Your worries are far from over, given that some other application may be installed on the target machine that overrides your carefully configured registry entries (and maybe even replaces a COM server or two with an earlier version during the process). Mysteriously, your client application may now fail to operate.
For example, if you have ten applications that all require the use of MyCOMServer.dll version 1.4, and
C# and the .NET Platform, Second Edition |
|
another application installs MyCOMServer.dll version 2.0, all ten applications are at risk of breaking. This is |
|
by Andrew Troelsen |
ISBN:1590590554 |
because we cannot be assured of complete backward compatibility. In a perfect world, all versions of a
Apress © 2003 (1200 pages)
given COM binary are fully compatible with previous versions. In practice however, keeping COM servers
This comprehensive text starts with a brief overview of the
(and software in general) completely backward compatible is extremely difficult.
C# language and then quickly moves to key technical and
architectural issues for .NET developers.
The lump sum of each of these versioning issues is lovingly referred to as "DLL Hell" (which, by the way, is not limited to COM DLLs; traditional C DLLs suffer the same hellish existence). As you'll see during the
course of this chapter, the .NET Framework solves this nightmare by using a number of techniques
Table of Contents
including side-by-side execution and a very robust (yet very simple) versioning scheme.
C# and the .NET Platform, Second Edition
IntroducIn a nutshell,ion .NET allows multiple versions of the same binary to be installed on the same target machine.
PartTherefore,One - Introunderucing.NET,C#ifandclienttheA.NETrequiresPlatformMyDotNETServer.dll version 1.4 and client B demands
ChapterMyDotNETServer1 - The Philosophy.dll versionof 2.NET.0, the correct version is loaded for the respective client automatically. You Chapterare also2 able- Buildingto bindC#to aApplicationsspecific version using an application configuration file.
Part Two - The C# Programming Language
ChapterProblem:3 - C#COMLanguageDeploymentFundamentals
Chapter 4 - Object-Oriented Programming with C#
ChapterThe COM5 -runtimeExceptionsis a andratherObjtemperamentalct Lifeti service. When a COM client wishes to make use of a Chaptercoclass,6 the- Interfacesfirst step isandto loadCollectionsthe COM libraries for a given thread by calling CoInitialize(). At this point,
the client makes additional calls to the COM runtime (e.g., CoCreateInstance(), CoGetClassObject(), and
Chapter 7 - Callback Interfaces, Delegates, and Events
so forth) to load a given binary into memory and create the required COM type. The result is that the COM
Chapter 8 - Advanced C# Type Construction Techniques
client receives an interface reference that is then used to manipulate the coclass.
Part Three - Programming with .NET Assemblies
Chapter 9 - Understanding .NET Assemblies
For the COM runtime to locate and load a binary, the COM server must be configured correctly on the
Chapter 10 - Processes, AppDomains, Contexts, and Threads
target machine. From a high level, registering a COM server sounds so simple: build an installation
Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming
program (or make use of a system-supplied registration tool) to trigger the correct logic in the COM binary
Part Four - Leveraging the .NET Libraries
(DllRegisterServer() for DLLs or WinMain() for EXEs) and call it a day. However, as you may know, a COM
Chapter 12 - Object Serialization and the .NET Remoting Layer
server requires a vast number of registration entries to be made. Typically, every COM class (CLSID),
Chapter 13 - Building a Better Window (Introducing Windows Forms)
interface (IID), type library (LIBID), and application (AppID) must be documented within the system registry.
Chapter 14 - A Better Painting Framework (GDI+)
The key point to keep in mind is that the relationship between the binary image and the related registry
Chapter 15 - Programming with Windows Forms Controls
entries is extremely loose, and therefore extremely fragile. In COM, the location of the binary image (e.g.,
Chapter 16 - The System.IO Namespace
C:\MyCOMServer.dll) is entirely separate from the massive number of registry entries that completely
Chapter 17 - Data Access with ADO.NET
describe the component. Therefore, if the end user were to relocate (or rename) a COM server, the entire
Part Five - Web Applications and XML Web Services
system breaks, as the registration entries are now out of sync.
Chapter 18 - ASP.NET Web Pages and Web Controls
Chapter 19 - ASP.NET Web Applications
The .NET platform makes the process of deploying an application extremely simple given the fact that
Chapter 20 - XML Web Services
.NET binaries (i.e., assemblies) are not registered in the system registry at all. Plain and simple. Deploying
Index
a .NET application can be (and most often is) as simple as copying the files that compose the application
List of Figures
to some location on the machine, and running your program. In short, be prepared to bid a fond farewell to ListHKEYof Tables_CLASSES_ROOT.