The .Net Framework relies heavily on the core premise of the Common Language Runtime (CLR), which .Net uses to translate various programming languages into Intermediate Language (IL). IL is the syntax used to send, receive, and manage .Net signals.
You can use any programming language that conforms to the Common Language Specification (CLS) to build .Net applications. Developers may come to a project with a variety of programming backgrounds, including disparate languages. But as long as the developers have a strong understanding of the .Net Framework, they can use their skills on a project.
First of two partsThis is the first of two articles that will discuss the core value of the CLR in Microsoft's plans for .Net. The second piece is here How does CLR work?
Within the domain of CLR are executables (consisting of code, data, and metadata), assemblies (consisting of a manifest and zero or more modules), and the Common Type System (CTS) convention set. When programmers write code in their favorite languages, that code is translated into IL prior to being compiled into a portable executable (PE). Executables
The main difference between a Windows PE and a .Net PE is that the Windows PE is executed by the operating system, but .Net PEs are turned over to the .Net Framework's CLR. Recognition of a PE as being .Net or Windows occurs because of the Common Object File Format (COFF) used by Windows operating systems. The COFF specifies two parts of any file: the file data itself and a bunch of header data describing the contents of the data portion. Note: To allow all Microsoft platforms to handle COFF modifications that enable .Net PEs, Microsoft has released new loaders for all of .Net's supported systems (98, 2000, and Me). Metadata
Metadata is information about a PE. In COM, metadata is communicated through non-standard type libraries. In .Net, this data is contained in the header portion of a COFF-compliant PE and follows certain guidelines; it contains information such as the assembly's name, version, language (spoken, not computer -- a.k.a., "culture"), what external types are referenced, what internal types are exposed, methods, properties, classes, and much more. The CLR uses metadata for a number of specific purposes. Security is managed through a public key in the PE's header. Information about classes, modules, and so forth allows the CLR to know in advance what structures are necessary. The class loader component of the CLR uses metadata to locate specific classes within assemblies, either locally or across networks. Just-in-time (JIT) compilers use the metadata to turn IL into executable code. Other programs take advantage of metadata as well. A common example is placing a Microsoft Word document on a Windows 2000 desktop. If the document file has completed comments, author, title, or other Properties metadata, the text is displayed as a tool tip when a user hovers the mouse over the document on the desktop. You can use the Ildasm.exe utility to view the metadata in a PE. Literally, this tool is an IL disassembler. Interoperability
Different types of files are handled by two different virtual systems in Windows and .Net. If a Windows executable is to interoperate with the .Net Framework, it interfaces with a COM wrapper for the desired .Net functionality, instead of accessing the functionality directly. Similarly, if a .Net application utilizes Windows (COM) objects, it needs a set of classes that expose the functionality, instead of accessing it directly. This communication between .Net and Windows is called "interoperability." Included in the .Net SDK are two sets of two tools each. One set is for .Net-to-COM operations, and the other is for COM-to-.Net operations. The first pair of tools consists of Regasm.exe and Tlbexp.exe. Regasm.exe registers a .Net Assembly in the Windows registry. Once this is done, the assembly is exposed as a COM object to the Windows OS. Developers who wish to access .Net Assemblies as COM objects in their own applications can use the Tlbexp.exe utility to export a Type Library TLB file to be referenced by their applications. The properties and methods of .Net Assembly are available, just as with any other COM object. The second pair of tools consists of TlbImp.exe and Xsd.exe. TlbImp.exe is run against a TLB file to create a .Net Assembly in the form of a dynamic-link library (DLL) file. Custom types in .Net are described through XML Schema Definitions (XSDs). When you run the Xsd.exe utility against an existing XSD file with the "/c" switch, the schema is converted to a C# class definition. As a sidenote, Xsd.exe also generates an XSD file from a .Net Assembly (using metadata in the COFF headers) when run against a .Net PE.
