This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

// C# method returning nothing.

public void MyMethod()

{

// Some interesting code...

}

C H A P T E R   1  

■

T H E   P H I L O S O P H Y   O F   . N E T

20

8849CH01.qxd  10/1/07  10:30 AM  Page 20

---

' VB method returning nothing.

Public Sub MyMethod()

' Some interesting code...

End Sub

As you have already seen, these minor syntactic variations are inconsequential in the eyes of

the .NET runtime, given that the respective compilers (csc.exe or vbc.exe, in this case) emit a simi-

lar set of CIL instructions. However, languages can also differ with regard to their overall level of

functionality. For example, a .NET language may or may not have a keyword to represent unsigned

data, and may or may not support pointer types. Given these possible variations, it would be ideal

to have a baseline to which all .NET-aware languages are expected to conform.

The CLS is a set of rules that describe in vivid detail the minimal and complete set of features a

given .NET-aware compiler must support to produce code that can be hosted by the CLR, while at

the same time be accessed in a uniform manner by all languages that target the .NET platform. In

many ways, the CLS can be viewed as a 

subset of the full functionality defined by the CTS.

The CLS is ultimately a set of rules that compiler builders must conform to, if they intend their

products to function seamlessly within the .NET universe. Each rule is assigned a simple name (e.g.,

“CLS Rule 6”) and describes how this rule affects those who build the compilers as well as those

who (in some way) interact with them. The crème de la crème of the CLS is the mighty Rule 1:

•

Rule 1: CLS rules apply only to those parts of a type that are exposed outside the defining

assembly.

Given this rule, you can (correctly) infer that the remaining rules of the CLS do not apply to the

logic used to build the inner workings of a .NET type. The only aspects of a type that must conform

to the CLS are the member definitions themselves (i.e., naming conventions, parameters, and

return types). The implementation logic for a member may use any number of non-CLS techniques,

as the outside world won’t know the difference.

To illustrate, the following Add() method is not CLS-compliant, as the parameters and return

values make use of unsigned data (which is not a requirement of the CLS):

class Calc

{