CLR via C# - CHAPTER 8 Methods

Methods

Instance Constructors and Classes (Reference Types)

When constructing a reference type object, the memory allocated for the object is always zeroed out before the type’s instance constructor is called. Any fields that the constructor doesn’t explicitly overwrite are guaranteed to have a value of 0or null.

If you define a class that does not explicitly define any constructors, the C# compiler defines a default (parameterless) constructor for you whose implementation simply calls the base class’s parameterless constructor.

Instance Constructors and Structures (Value Types)

Value types don’t actually even need to have a constructor defined within them, and the C# compiler doesn't emit default parameterless constructors for value types.

The CLR does allow you to define constructors on value types. The only way that these constructors will execute is if you write code to explicitly call one of them,

The trick part is that C# doesn’t allow a value type to define a parameterless constructor.

As an alternative way to initialize all the fields of a value type, you can actually do the following.
// C# allows value types to have constructors that take parameters.
public SomeValType(Int32 x) {
// Looks strange but compiles fine and initializes all fields to 0/null.
this = new SomeValType();
m_x = x; // Overwrite m_x's 0 with x
// Notice that m_y was initialized to 0.
}
In a value type’s constructor, thisrepresents an instance of the value type itself and you can actually assign to it the result of newing up an instance of the value type, which really just zeroes out all the fields.

Type Constructors
If a type has a type constructor, it can have no more than one. In addition, type constructors never have parameters.

Because the CLR guarantees that a type constructor executes only once per AppDomain and is thread-safe, a type constructor is a great place to initialize any singleton objects required by the type.

In fact, because the CLR is responsible for calling type constructors, you should always avoid writing any code that requires type constructors to be called in a specific order.

CLR via C# - CHAPTER 7 Constants and Fields

Constants and Fields

Constants

When code refers to a constant symbol, compilers look up the symbol in the metadata of the assembly that defines the constant, extract the constant’s value, and embed the value in the emitted Intermediate Language (IL) code.

Fields

However, readonly fields can be written to only within a constructor method (which is called only once, when an object is first created). 

When a field is of a reference type and the field is marked as readonly, it is the reference that is immutable, not the object that the field refers to.

CLR via C# - CHAPTER 6 Type and Member Basics

 Type and Member Basics

The Different Kinds of Type Members

Friend Assemblies
When an assembly is built, it can indicate other assemblies it considers “friends” by using the InternalsVisibleToattribute defined in the System.Runtime.CompilerServicesnamespace.

When the type of a field, method parameter, or method return using System;
using System.Runtime.CompilerServices; // For InternalsVisibleTo attribute
// This assembly's internal types can be accessed by any code written
// in the following two assemblies (regardless of version or culture):
[assembly:InternalsVisibleTo("Wintellect, PublicKey=12345678...90abcdef")]
[assembly:InternalsVisibleTo("Microsoft, PublicKey=b77a5c56...1934e089")]
internal sealed class SomeInternalType { ... }
internal sealed class AnotherInternalType { ... }

Member Accessibility

The CLR requires that all members of an interface type be public. The C# compiler knows this and forbids the programmer from explicitly specifying accessibility on interface members; the compiler just makes all the members publicfor you.

When a derived type is overriding a member defined in its base type, the C# compiler requires that the original member and the overriding member have the same accessibility. That is, if the member in the base class is protected, the overriding member in the derived class must also be protected. However, this is a C# restriction, not a CLR restriction. When deriving from a base class, the CLR allows a member’s accessibility to become less restrictive but not more restrictive. For example, a class can override a protectedmethod defined in its base class and make the overridden method public(more accessible). However, a class cannot override a protectedmethod defined in its base class and make the overridden method private(less accessible). The reason a class cannot make a base class method more restricted is because a user of the derived class could always cast to the base type and gain access to the base class’s method. If the CLR allowed the derived type’s method to be less accessible, it would be making a claim that was not enforceable.

Static Classes
The compiler enforces many restrictions on a staticclass:
■ The class must be derived directly from System.Objectbecause deriving from any other base class makes no sense because inheritance applies only to objects, and you cannot create an instance of a staticclass.
■ The class must not implement any interfaces because interface methods are callable only when using an instance of a class.
■ The class must define only staticmembers (fields, methods, properties, and events). Any instance members cause the compiler to generate an error.
■ The class cannot be used as a field, method parameter, or local variable because all of these would indicate a variable that refers to an instance, and this is not allowed. If the compiler detects any of these uses, the compiler issues an error.

Defining a class by using the statickeyword causes the C# compiler to make the class both abstractand sealed. Furthermore, the compiler will not emit an instance constructor method into the type.

Partial Classes, Structures, and Interfaces

Components, Polymorphism, and Versioning

How the CLR Calls Virtual Methods, Properties, and Events

Using Type Visibility and Member Accessibility Intelligently

Dealing with Virtual Methods When Versioning Types

CLR via C# - CHAPTER 5 Primitive, Reference, and Value Types

Primitive, Reference, and Value  Types

Programming Language Primitive Types
Any data types the compiler directly supports are called primitive types. Primitive types map directly to types existing in the Framework Class Library (FCL).

Reference Types and Value Types
The CLR supports two kinds of types: reference types and value types.Value type instances are usually allocated on a thread’s stack.
The .NET Framework SDK documentation clearly indicates which types are reference types and which are value types.When looking up a type in the documentation, any type called a class is a reference type. On the other hand, the documentation refers to each value type as a structure or an enumeration.

All of the structures are immediately derived from the System.ValueTypeabstract type. System.Value Typeis itself immediately derived from the System.Objecttype. By definition, all value types must be derived from System.ValueType. All enumerations are derived from the System.Enumabstract type, which is itself derived from System.ValueType.

Object Equality and Identity
When defining your own type, if you decide to override Equals, you must ensure that it adheres
to the four properties of equality:
■ Equalsmust be reflexive; that is, x.Equals(x)must return true.
■ Equalsmust be symmetric; that is, x.Equals(y)must return the same value as y.Equals(x).
■ Equalsmust be transitive; that is, if x.Equals(y)returns trueand y.Equals(z)returns true, then x.Equals(z)must also return true.
■ Equalsmust be consistent. Provided that there are no changes in the two values being compared, Equalsshould consistently return trueor false.

When overriding the Equalsmethod, there are a couple more things that you’ll probably want
to do:
■ Have the type implement the System.IEquatable<T>interface’s Equalsmethod  This generic interface allows you to define a type-safe Equalsmethod. Usually, you’ll implement the Equalsmethod that takes an Objectparameter to internally call the type-safe Equals method.
■ Overload the ==and !=operator methods  Usually, you’ll implement these operator methods to internally call the type-safe Equalsmethod.

Object Hash Codes
If you define a type and override the Equalsmethod, you should also override the GetHashCode method.
The reason a type that defines Equalsmust also define GetHashCodeis that the implementation of the System.Collections.Hashtabletype, the System.Collections.Generic.Dictionary type, and some other collections require that any two objects that are equal must have the same hash code value.

Basically, when you add a key/value pair to a collection, a hash code for the key object is obtained first. This hash code indicates which “bucket” the key/value pair should be stored in. When the collection needs to look up a key, it gets the hash code for the specified key object. This code identifies the “bucket” that is now searched sequentially, looking for a stored key object that is equal to the specified key object.

When selecting an algorithm for calculating hash codes for instances of your type, try to follow these guidelines:
■ Use an algorithm that gives a good random distribution for the best performance of the hash table.
■ Your algorithm can also call the base type’s GetHashCodemethod, including its return value. However, you don’t generally want to call Object’s or ValueType’s GetHashCodemethod, because the implementation in either method doesn’t lend itself to high-performance hashing algorithms.
■ Your algorithm should use at least one instance field.
■ Ideally, the fields you use in your algorithm should be immutable; that is, the fields should be initialized when the object is constructed, and they should never again change during the object’s lifetime.
■ Your algorithm should execute as quickly as possible.
■ Objects with the same value should return the same code. For example, two Stringobjects with the same text should return the same hash code value.

The dynamicPrimitive Type
payload code

When the type of a field, method parameter, or method return type is specified as dynamic, the compiler converts this type to the System.Objecttype and applies an instance of System.Run­time.CompilerServices.DynamicAttribute to the field, parameter, or return type in metadata. If a local variable is specified as dynamic, then the variable’s type will also be of type Object, but the DynamicAttributeis not applied to the local variable because its usage is self-contained within the method. Because dynamicis really the same as Object, you cannot write methods whose signature differs only by dynamicand Object.
It is also possible to use dynamicwhen specifying generic type arguments to a generic class (reference type), a structure (value type), an interface, a delegate, or a method. When you do this, the compiler converts dynamicto Objectand applies DynamicAttributeto the various pieces of metadata where it makes sense. Note that the generic code that you are using has already been compiled and will consider the type to be Object; no dynamic dispatch will be performed because the compiler did not produce any payload code in the generic code.
Any expression can implicitly be cast to dynamicbecause all expressions result in a type that is rived from Object Normally, the compiler does not allow you to write code that implicitly casts an expression from Objectto another type; you must use explicit cast syntax. However, the compiler does allow you to cast an expression from dynamicto another type by using implicit cast syntax.

CLR via C# - CHAPTER 4 Type Fundamentals

Type Fundamentals

How Things Relate at Run Time

CLR via C# - CHAPTER 3 Shared Assemblies and Strongly Named Assemblies

Shared Assemblies and Strongly Named Assemblies

Two Kinds of Assemblies, Two Kinds of Deployment
The real difference between weakly named and strongly named assemblies is that a strongly named assembly is signed with a publisher’s public/private key pair that uniquely identifies the assembly’s publisher. This key pair allows the assembly to be uniquely identified, secured, and versioned, and it allows the assembly to be deployed anywhere on the user’s machine or even on the Internet.

A strongly named assembly consists of four attributes that uniquely identify the assembly: a file name (without an extension), a version number, a culture identity, and a public key. Because public keys are very large numbers, we frequently use a small hash value derived from a public key. This hash value is called a public key token.

A strongly named assembly consists of four attributes that uniquely identify the assembly: a file name (without an extension), a version number, a culture identity, and a public key. Because public keys are very large numbers, we frequently use a small hash value derived from a public key. This hash value is called a public key token.

SN –k MyCompany.snk
This line tells SN.exe to create a file called MyCompany.snk. This file will contain the public and private key numbers persisted in a binary format.

First, you invoke SN.exe with the –pswitch to create a file that contains only the public key (MyCompany.PublicKey)
SN –p MyCompany.snk MyCompany.PublicKey sha256
Then, you invoke SN.exe, passing it the –tpswitch and the file that contains just the public key.
SN –tp MyCompany.PublicKey

A public key token is a 64-bit hash of the public key.

When you compile your assembly, you use the /keyfile:<file>compiler switch.
csc /keyfile:MyCompany.snk Program.cs

 These reduced public key values—known as public key tokens—are what are actually stored in an AssemblyRef table.
By the way, the Assembly Def entry always stores the full public key, not the public key token.

The Global Assembly Cache
As you can see, you can invoke GACUtil.exe, specifying the /iswitch to install an assembly into the GAC, and you can use GACUtil.exe’s /uswitch to uninstall an assembly from the GAC.
By default, the GAC can be manipulated only by a user belonging to the Windows Administrators group.

First, you invoke SN.exe with the –pswitch to create a file that contains only the public key (MyCompany.PublicKey)
SN –p MyCompany.snk MyCompany.PublicKey sha256
Then, you invoke SN.exe, passing it the –tpswitch and the file that contains just the public key.
SN –tp MyCompany.PublicKey

Using GACUtil.exe’s /iswitch is very convenient for developer testing. However, if you use GACUtil.exe to deploy an assembly in a production environment, it’s recommended that you use GACUtil.exe’s /rswitch in addition to specifying the /ior /uswitch to install or uninstall the assembly. The /rswitch integrates the assembly with the Windows install and uninstall engine. Basically, it tells the system which application requires the assembly and then ties the application and the assembly together.

MSI is the only tool that is guaranteed to be on end-user machines and capable of installing assemblies into the GAC. 

Building an Assembly That References a Strongly Named Assembly
Yousee, when you install the .NET Framework, two copies of Microsoft’s assembly files are actually installed. One set is installed into the compiler/CLR directory, and another set is installed into a GAC subdirectory. The files in the compiler/CLR directory exist so that you can easily build your assembly, whereas the copies in the GAC exist so that they can be loaded at run time.

In addition, the assemblies in the compiler/CLR directory are machine agnostic. That is, these assemblies contain only metadata in them. Because the IL code is not required at build time, this directory does not have to contain x86, x64, and ARM versions of an assembly. The assemblies in the GAC contain metadata and IL code because the code is needed only at run time.

Strongly Named Assemblies Are Tamper-Resistant
When an assembly is installed into the GAC, the system hashes the contents of the file containing the manifest and compares the hash value with the RSA digital signature value embedded within the PE file (after unsigning it with the public key). If the values are identical, the file’s contents haven’t been tampered with. In addition, the system hashes the contents of the assembly’s other files and compares the hash values with the hash values stored in the manifest file’s FileDef table.

Delayed Signing
The .NET Framework supports delayed signing, sometimes referred to as partial signing.
When an assembly is installed into the GAC, the system hashes the contents of the file containing the manifest and compares the hash value with the RSA digital signature value embedded within the PE file (after unsigning it with the public key). If the values are identical, the file’s contents haven’t been tampered with. In addition, the system hashes the contents of the assembly’s other files and compares the hash values with the hash values stored in the manifest file’s FileDef tableaYou must also tell the tool that you want the assembly to be delay signed, meaning that you’re not supplying a private key. For the C# compiler, you do this by specifying the /delaysigncompiler switch. In Visual Studio, you display the properties for your project, click the Signing tab, and then select the Delay Sign Only check box. If you’re using AL.exe, you can specify the /delay[sign]commandline switch.

When creating the resulting assembly, space is left in the resulting PE file for the RSA digital signature. (The utility can determine how much space is necessary from he size of the public key.) Note that the file’s contents won’t be hashed at this time either.

On every machine on which the assembly needs to be installed into the GAC, you must prevent the system from verifying the integrity of the assembly’s files. To do this, you use the SN.exe utility, specifying the –Vrcommand-line switch.

After this step, you can deploy the fully signed assembly. On the developing and testing machines, don’t forget to turn verification of this assembly back on by using SN.exe’s –Vuor –Vxcommand-line switch.

the steps to develop your assembly by using the delayed signing technique
1. csc /keyfile:MyCompany.PublicKey /delaysign MyAssembly.cs
2. SN.exe –Vr MyAssembly.dll
3. SN.exe ­Ra MyAssembly.dll MyCompany.PrivateKey
4. SN.exe –Vu MyAssembly.dll

So, if you want to obfuscate an assembly file or perform any other type of post-build operation, you should use delayed signing, perform the post-build operation, and then run SN.exe with the –R or –Rc switch to complete the signing process of the assembly with all of its hashing.

Delayed signing is also useful whenever you want to perform some other operation to an assembly before you package it. For example, you may want to run an obfuscator over your assembly.

Privately Deploying Strongly Named Assemblies
codeBase

How the Runtime Resolves Type References

However, the .NET Framework assemblies (including MSCorLib.dll) are closely tied to the version of the CLR that’s running. Any assembly that references .NET Framework assemblies always binds to the version that matches the CLR’s version.
However, the GAC identifies assemblies by using name, version, culture, public key, and CPU architecture.

When searching the GAC for an assembly, the CLR first searches for a CPU architecture–specific version of the assembly. If it does not find a matching assembly, it then searches for a CPU-agnostic version of the assembly.

Advanced Administrative Control (Configuration)
<?xml version="1.0"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">
<probing privatePath="AuxFiles;bin\subdir" />
<dependentAssembly>
<assemblyIdentity name="SomeClassLibrary" publicKeyToken="32ab4ba45e0a69a1" culture="neutral"/>
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
<codeBase version="2.0.0.0" href="http://www.Wintellect.com/SomeClassLibrary.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="TypeLib" publicKeyToken="1f2e74e897abbcfe" culture="neutral"/>
<bindingRedirect oldVersion="3.0.0.0­3.5.0.0" newVersion="4.0.0.0" />
<publisherPolicy apply="no" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

Publisher Policy Control
AL.exe /out:Policy.1.0.SomeClassLibrary.dll
/version:1.0.0.0
/keyfile:MyCompany.snk
/linkresource:SomeClassLibrary.config


<publisherPolicy apply="no"/>

CLR via C# - CHAPTER 2 Building, Packaging, Deploying, and Administering Applications and Types

Building, Packaging, Deploying, and Administering Applications and Types

If, for some reason, you really don’t want the C# compiler to reference the MSCorLib.dll assembly, you can use the /nostdlibswitch.
csc.exe /out:Program.exe /t:exe /nostdlib Program.cs

To build a console user interface (CUI) application, specify the /t:exeswitch; to build a graphical user interface (GUI) application, specify the /t:winexeswitch; and to build a Windows Store app, specify the /t:appcontainerexeswitch.

Response Files
A response file is a text file that contains a set of compiler command-line switches.

Whenyou use the /referencecompiler switch to reference an assembly, you can specify a complete path to a particular file. However, if you do not specify a path, the compiler will search for the file in the following places (in the order listed):
■ Working directory.
■ The directory that contains the CSC.exe file itself. MSCorLib.dll is always obtained from this directory. The path looks something like this: %SystemRoot%\Microsoft.NET\Framework\v4.0.#####.
■ Any directories specified using the /libcompiler switch.
■ Any directories specified using the LIBenvironment variable.

Also, you can tell the compiler to ignore both local and global CSC.rsp files by specifying the /noconfig command-line switch.

A Brief Look at Metadata
Nowwe know what kind of PE file we’ve created. But what exactly is in the Program.exe file? A managed PE file has four main parts: the PE32(+) header, the CLR header, the metadata, and the IL. The PE32(+) header is the standard information that Windows expects. The CLR header is a small block of information that is specific to modules that require the CLR (managed modules). The header includes the major and minor version number of the CLR that the module was built for: some flags,a  MethodDeftoken (described later) indicating the module’s entry point method if this module is a CUI, GUI, or Windows Store executable, and an optional strong-name digital signature (discussed in Chapter 3). Finally, the header contains the size and offsets of certain metadata tables contained within the module. You can see the exact format of the CLR header by examining the IMAGE_COR20_HEADER
defined in the CorHdr.h header file.
Themetadata is a block of binary data that consists of several tables. There are three categories of tables: definition tables, reference tables, and manifest tables. Table 2-1 describes some of the more common definition tables that exist in a module’s metadata block.

The metadata created includes a set of reference tables that keep a record of the referenced items.

ILDasm Program.exe

Combining Modules to Form an Assembly
The manifest is another set of metadata tables that basically contain the names of the files that are part of the assembly. They also describe the assembly’s version, culture, publisher, publicly exported types, and all of the files that comprise the assembly.

The CLR operates on assemblies; that is, the CLR always loads the file that contains the manifest metadata tables first and then uses the manifest to get the names of the other files that are in the assembly.Here are some characteristics of assemblies that you should remember:
■ An assembly defines the reusable types.
■ An assembly is marked with a version number.
■ An assembly can have security information associated with it.

An assembly’s individual files don’t have these attributes—except for the file that contains the manifest metadata tables.

To build an assembly, you must select one of your PE files to be the keeper of the manifest. Or you can create a separate PE file that contains nothing but the manifest.

he C# compiler produces an assembly when you specify any of the following command-line switches: /t[arget]:exe, /t[arget]:winexe, /t[arget]: appcontainerexe, /t[arget]:library, or /t[arget]:winmdobj.

In addition to these switches, the C# compiler supports the /t[arget]:moduleswitch. This switch tells the compiler to produce a PE file that doesn’t contain the manifest metadata tables. The PE file produced is always a DLL PE file, and this file must be added to an assembly before the CLR can access any types within it. When you use the /t:moduleswitch, the C# compiler, by default, names the output file with an extension of .netmodule.

Unfortunately, the Microsoft Visual Studio integrated development environment (IDE) doesn’t natively support the ability for you to create multifile assemblies. If you want to create multifile assemblies, you must resort to using command-line tools.

Thereare many ways to add a module to an assembly. If you’re using the C# compiler to build a PE file with a manifest, you can use the /addmoduleswitch.

csc /out:MultiFileLibrary.dll /t:library /addmodule:RUT.netmodule FUT.cs

Using the Assembly Linker
csc /t:module RUT.cs
csc /t:module FUT.cs
al /out: MultiFileLibrary.dll /t:library FUT.netmodule RUT.netmodule

csc /t:module /r:MultiFileLibrary.dll Program.cs
al /out:Program.exe /t:exe /main:Program.Main Program.netmodule

Adding Resource Files to an Assembly

AL.exe /embed[resource]switch /link[resource]switch
CSC.exe /resourceswitch /linkresourceswitch

One last note about resources: it’s possible to embed standard Win32 resources into an assembly. You can do this easily by specifying the path of a .res file with the /win32resswitch when using either AL.exe or CSC.exe.
In addition, you can quickly and easily embed a standard Win32 icon resource into an assembly file by specifying the path of the .ico file with the /win32iconswitch when using either AL.exe or CSC.exe.

Assembly Version Resource Information

Version Numbers

AssemblyFileVersion
This version number is stored in the Win32 version resource.This number is for information purposes only; the CLR doesn’t examine this version number in any way.

AssemblyInformationalVersion.
This version number is also stored in the Win32 version resource, and again, this number is for information purposes only; the CLR doesn’t examine or care about it in any way. This version number exists to indicate the version of the product that includes this assembly.

AssemblyVersion
This version number is stored in the AssemblyDef manifest metadata table. The CLR uses this version number when binding to strongly named assemblies (discussed in Chapter 3). This number is extremely important and is used to uniquely identify an assembly.


Culture

Assemblies that are marked with a culture are called satellite assemblies.

You’ll usually use the AL.exe tool to build a satellite assembly. You won’t use a compiler because the satellite assembly should have no code contained within it.
When using AL.exe, you specify the desired culture by using the /c[ulture]:textswitch, where textis a string such as “en-US,” representing US English. When you deploy a satellite assembly, you should place it in a subdirectory whose name matches the culture text. For example, if the application’s base directory is C:\MyApp, the US English satellite assembly should be placed in the C:\MyApp\en-US subdirectory. At run time, you access a satellite assembly’s resources by using the System.Resources.ResourceManagerclass.

Simple Application Deployment (Privately Deployed Assemblies)

Simple Administrative Control (Configuration)

AppDir directory (contains the application’s assembly files)
Program.exe
Program.exe.config (discussed below)

AuxFiles subdirectory (contains MultiFileLibrary’s assembly files)
MultiFileLibrary.dll
FUT.netmodule
RUT.netmodule

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">
<probing privatePath="AuxFiles" />
</assemblyBinding>
</runtime>
</configuration>