Edited by a Lead Program Manager on Microsoft's .NET Framework team, .NET Framework Standard Library Annotated Reference, Volume 1, is the definitive reference for the .NET Framework base class library. This book utilizes extensive annotations and code samples from the creators of the technology to move beyond the online documentation and provide .NET developers with a dictionary-style reference to the most-used parts of the Framework. This volume covers a subset of the ISO CLI Standards, including the Base Class Library and the Extended Numerics Library.
In the printed book you will find informative overviews of each namespace covered and an easy-to-follow alphabetic reference of types in the standard, including type-level descriptions, sample code with output, and annotations from the design team and standardization committee.
With the ECMA and ISO standards as its core, this book includes:
Download the CD
Excerpt file related to this title.
Download the Sample
Chapter related to this title.
Annotations Index 519
When I began my standards "career" back in August 2000, "ECMA" and "ISO" meant as much to me as the sequence of letters in the daily newspaper jumble. I hadn't a clue on how the standards process actually worked, from either a technical or a political perspective. Now, as I write this, I am chair of the ECMA committee that oversees the standardization of programming and scripting languages. In addition, I am convener of the task group within the committee that is responsible for the standardization of the CLI, on which, of course, the content of this book is based.
In 2000, Microsoft publicly introduced its .NET vision. A key component of this vision is the .NET Framework, which includes a set of class libraries and a virtual machine ("runtime engine") to execute next-generation applications.
In September 2000, Microsoft, co-sponsored by Intel and Hewlett-Packard, formally submitted a core subset of the .NET Framework to ECMA International, a renowned international standards organization. The submission was entitled the Common Language Infrastructure, or CLI. The meeting was held in Bristol, England, with representatives from companies such as IBM and Sun Microsystems. Microsoft presented the CLI to ECMA's Programming and Scripting Languages Technical Committee, or TC39. It was decided by unanimous consent that the CLI would be added to the program of work for TC39 and that a new task group, called the TG3, would be responsible for the standardization effort. One might ask what happened to TG1 and TG2. Before the submission of the CLI, the TC39 was responsible for the standardization of only ECMAScript. There were no task groups, per se. When the CLI was approved for work, ECMAScript was moved to a newly formed TG1. C#, which was submitted at the same time as the CLI, introduced the TG2. The TG3 was reserved for the CLI. There is now even a TG4 responsible for the standardization of the Eiffel programming language and a TG5 chartered to standardize a binding between ISO C++ and the CLI.
There are two primary facets to the CLI standardization process within ECMA, the virtual machine and the class libraries. The virtual machine provides the environment necessary to execute applications written for the CLI. The class libraries provide the core infrastructure to enable developers to create libraries and applications for execution on top of the virtual machine.
I am involved in both facets of the standardization process, but I have enjoyed the class library aspect the most. This is primarily because I have a better understanding of that level of the development stack than I do the lower layers, such as where the virtual machine would lie. And since Brad Abrams was the Microsoft lead in the class library standardizatio effort, my good relationship with him began.
The set of class libraries submitted to ECMA International are, from a .NET Framework perspective, relatively small. However, they definitely provide the foundation upon which all other class libraries are built. The class library was segmented into what the standard calls "profiles." The kernel profile consists of the base types that would be expected to exist in modern programming languages (as well as types to assist compilers for those languages). String and Int32 are examples of such types. The kernel profile must be implemented in order to claim conformance to the standard. The compact profile consists of the kernel pro- file, plus some types necessary to implement basic Web services-type applications while maintaining a small enough footprint to fit on standard compact, connected devices. Then there are some types that do not fit any profile, but can be implemented as part of any profile. These include types dealing with floating point numbers and multidimensional arrays. Brad's book concentrates on the base types that are part of the kernel profile, as well as the extended numerics (e.g., floating point and decimal). For information on the concept behind the segmentation of the class libraries into profiles, see Partition IV of the ECMA Standard ECMA-335, also published as ISO/IEC 23271. The ECMA Standard can be downloaded-- and freely copied--free of charge from http://www.ecma-international.org.
The process by which we standardized the base types associated with kernel profile was systematic, and yet churned out some very interesting and heated discussion. There was an initial cursory review of all of the libraries in order to weed out any obvious errors and missing data. Then came the detailed reviews. We started with the type of all types, System.Object. This served as the model of the process we would use to do the rest of the detailed reviews. The task group members would work offline and formulate individual comments on the type. Then at the meeting we would go page by page, method by method, property by property to see if there were any comments. Brad, who managed the editing process at Microsoft, took the comments back and incorporated them. Finally, the task group would review the type again with the incorporated changes and consider it final. Of course, if the task group just reviewed one type per meeting, we would still be reviewing the class libraries. After System.Object, the base types were divided into relatively equal parts, and at each meeting the task group would review one of those parts. To expedite the process, a subgroup of people were assigned as primary reviewers for certain types. Thus, committee members weren't overwhelmed by having to do detailed analysis and commentary on all types.
If all we did at the meetings were editorial reviews of the types--fixing punctuation here and changing a word there--they would have been quite boring. (Actually, come to think of it, it would have been amazing if that were the case--no substantial changes were needed to the class libraries because they were already perfect!) I mentioned that some interesting and heated discussion occurred during the reviews of the class libraries. This was because they were, of course, not perfect, and thus illustrate the benefit and relevance of the standardization process. You will see many annotations in this book that are examples of cool discussion, so I won't dive into it much here, but one instance definitely sticks out as a whopper. It was within the System.Decimal structure, where the original speci- fication of the ToString() method did not preserve the scale (trailing zeros) during conversion (even though it maintained scale internally, it was not exposed through conversions back and forth from String). For example, given a decimal value of 134.320000, it can be noted that this has a scale of 6. Calling the ToString() method would produce a string with the characters 134.32, making a decimal value with a scale of 2. This was deemed the wrong thing to do. Now one must remember that the .NET Framework 1.0 had already been shipped to millions of customers. Even so, the change was made to the specification and, even more important, Microsoft staff agreed to this change even though it would break code. They knew, however, it was the right thing to do. Indeed, standardization can be quite interesting!
The class library specifications were submitted to ECMA International, but not as the Microsoft Word or Adobe PDF documentation that one would expect. Instead they were submitted in XML format. This was done for various reasons, but the primary one was so that implementers could create documentation in any form they chose (HTML, Word, PDF, etc.) using well-known XSLT techniques and other mechanisms. It allowed for a lot of freedom in the documentation. Of course, no one (at least no one of sound mind) is going to read 10 MB of raw XML, let alone use it as the means to review the types. Thus a way to convert the XML to Word was needed. A managed code-based tool was developed by one of the task group members using XSLT and COM Interop to access the Word APIs (I am usually very humble, so I won't mention the tool author by name, but...). This turned out to be very valuable because it produced human-readable documentation. It also saved months of manual editing and formatting because the tool allowed edits to be made to the XML only, and then it would take care of the rest. The tool was also versatile. It did not just generate Word documents. For example, the type, method, and property signatures you see in this book--even those in the C# standard--are based on the running of the conversion tool. It was actually quite fun to develop. Not everyone was convinced of the benefits of the XML, and there was some controversy regarding the submission of the class libraries in that format (although ECMA had already developed another standard in this format); it even caused one delegation within ISO to vote against accepting the standard at first. After discussion, however, the XML format was accepted as an appropriate submission mechanism. The tool, and the results it produces, is published as ECMA TR/84, which is also freely available from the ECMA Web site.
Some people may ask why the CLI was submitted for standardization in the first place. Yes, it's true that the current standard CLI specification alone will not allow developers to implement a majority of real-world applications (e.g., I doubt Quake could be etched out of the standard library set). However, it is, in my mind, a near-perfect base to begin such an implementation. Also, the industry has accepted the standard. Intel's Open Class Libraries (OCL), as well as other public projects, are based on what the standard has to offer (the licensing arrangements for the standard are very kind, which helps here, but I won't get into that). It provides a cookbook for researchers to do work in the area of managed runtime environments, knowing that this cookbook is based on a highquality and widely used commercial implementation. It also provides a foundation for future technologies to be added to the standard, which is already evident in the work happening to the next edition of the standard.
The first edition of the standard was ratified by ECMA in December 2001, and approved by ISO in October 2002 (which became Edition 2 of the ECMA standard in December 2002 because minor edits were made during the ISO review process). Work on Edition 3 is occurring as I write this, and some interesting libraries are being considered in the area of generics and threading.
The specification itself, while important in implementing the CLI class libraries, could be construed as very dry reading. It is, after all, primarily a cookbook specifying what must be included in a successful class library recipe. .NET Framework Standard Library Annotated Reference, Volume 1, adds some pizzazz to the standard. Annotations are not typically an official part of a standard, and rightly so, as a standard must be as clear and concise as possible, only providing necessary information for implementation. However, if I were a developer using the CLI class libraries (heck, even if I were an implementer of the libraries), this book would be my primary tool. Why? Because it provides you with all the information of the official standard, but also includes firsthand insight, examples, and occasionally a little humor by those who developed it. And those added extras could answer a lot of the "Why was this done that way?" questions that many developers have.
Some quick praise for the author of this book, Brad Abrams: It is obvious that he is a content guru. In addition, it was his leadership in producing the specifications, accepting (most of the time) and incorporating changes, and reproducing the results in a timely manner, that enabled this standard to be produced in the time frame it was.
For me, the journey from alphabet soup to where we are today has been an interesting ride. I like to think my hard work during the process and my passion for what was being standardized led me to the ECMA positions I hold today. But if it weren't for the dedication of people like Brad, who was instrumental in getting the first edition of the standard out the door, I am not sure there would be such positions in the first place.
Step into the minds of the people who actually made the standard class libraries happen, and enjoy the book.
Chair of TC39
Convener of TG3
The views expressed in this Foreword do not necessarily reflect the views of Intel Corporation, its affiliates, its subsidiaries, or its employees.
Download the Index
file related to this title.