Not sure how many of us really understand how the CLR resolves type references, but if you are interested in knowing how this happens, i would strongly suggest you to go through the below flowchart. The chart, i feel is pretty much self explanatory. This flowchart is from Jeffrey Richter's book on Applied Microsoft .Net Framework Programming in which he has explained the process in detail. The second edition of this book called CLR via C# is also available. The second edition talks about the new features in .Net 2.0 in addition to the other CLR features.
machine.config has default settings for all applications on your machine, and the application configuration file has settings just for the application. The application settings override the settings in
The technical explanation requires looking at the
Create method of
IConfigurationSectionHandler. This method is implemented by all configuration section handlers and looks like this:
object Create(object parent, object configContext, XmlNode section);
section parameter is the XML for that section, the
configContext parameter is only relevant to ASP.NET and will be ignored here.
GetConfig will call this twice: once for the section in
machine.config and then once more for the section in the application config file. The handler should process the XML and use this information to create a configuration object which is returned from
Create. If the call to
machine.config returns a configuration object, then this object is passed as the
parent parameter to the subsequent call to
Create for the application config file. It's entirely up to the handler to determine what it must do with this parent object, but clearly the most logical thing to do is to use the values as default values and if there are equivalent values in the application configuration file, then the parent values will be overwritten.
The May 2006 preview of the Language-Integrated Query (LINQ) technology contains .NET Framework enhancements to support querying data, VB and C# language extensions, Visual Studio 2005 integration (editing, designing and debugging), plus samples, hands on labs and whitepapers.
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).
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 is information about a PE. In COM, metadata is communicated through nonstandardized 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.
To build software that meets your security objectives, you must integrate security activities into your software development lifecycle. Microsoft has released a handbook which captures and summarises the key security engineering activities that should be an integral part of your software development processes.
These security engineering activities have been developed by Microsoft patterns & practices to build on, refine and extend core lifecycle activities with a set of security-specific activities. These include identifying security objectives, applying design guidelines for security, threat modelling, security architecture and design reviews, security code reviews and security deployment reviews.
The .NET Framework Base Class Library (BCL) consists of thousands of classes covering almost all of the functionality required to create powerful applications. Certain functionality,—such as changing the windows resolution or muting and unmuting sounds,—can only be accomplished with Win32 API calls or functions in other unmanaged DLLs (Dynamic Link Libraries). Unmanaged code is code that runs outside of the Common Language Runtime (CLR). Examples include COM and ActiveX components written in C or C++ as well as Win32 API functions.
Learn how to use P/Invoke to call unmanaged Win32 APIs from managed code. These sample applications show how to mute sounds, change Windows resolution, and display balloon tips from your managed code.
The Native Image Generator creates a native image from a managed assembly and installs it into the native image cache on the local computer. The native image cache is a reserved area of the global assembly cache. Once you create a native image for an assembly, the runtime automatically uses that native image each time it runs the assembly. You do not have to perform any additional procedures to cause the runtime to use a native image. Running Ngen.exe on an assembly allows the assembly to load and execute faster, because it restores code and data structures from the native image cache rather than generating them dynamically. More…