#957 – Naming Files that Contain C# Code

Files that contain C# code are typically named using a .cs extension.  You can, however, include C# in a code having any extension you like.  Note that in Visual Studio, if the extension is other than .cs, you’ll need to set the Build Action to Compile.  The editor will also not use Intellisense on files having other extensions, unless you specifically change this.

A file containing C# code is most often named to represent a single class or type that it contains.  This helps in finding the source code that contains a particular class.



You can, however, store any type that you like within a particular file.



You might also store several types within the same file.



You can also split the implementation of a class across multiple files, using the partial keyword.


#956 – The Common Language Infrastructure (CLI)

The Common Language Infrastructure (CLI) is a definition for the environment in which managed applications run.

The CLI is both language- and platform-neutral:

  • You can write a CLI-compliant application in a number of different languages
    • E.g. C#, Visual Basic .NET, F#
  • You can execute a CLI-compliant applicaton on any platform where an implementation of the CLI is running
    • E.g. Windows (Common Language Runtime), OS X (Mono)

Microsoft’s Common Language Runtime (CLR) is an implementation of the CLI that runs on Windows.  Mono is an implementation of the CLI that runs on several platforms, including Android, Linux and OS X.

The CLI includes:

  • Common Type System (CTS) – defines of a set of types and rules associated with those types
  • Common Language Specification (CLS) – defines a subset of the CTS that allows modules written in different languages to interoperate
  • Virtual Execution System (VES) – a runtime environment that enforces the CTS

#955 – C# Is a Managed Language

When you author code in C#, you’re writing managed code.  That is, you’re creating a managed application.

Managed code runs within the context of the Common Language Runtime (CLR).  The CLR is a run-time environment that executes managed code and provides basic services to your application like a standard type system, memory management, and exception handling.

Managed code can be written in a number of different languages, including (but not limited to) C#, Visual Basic, and Managed C++.  The compiler for the associated language converts the code into Microsoft Intermediate Language (MSIL), which is consumed by the CLR and then compiled by a Just in Time Compiler (JIT) into machine-specific instructions.

Managed code can execute not only within Microsoft’s CLR, running on Windows, but also on other third-party CLR implementations. (E.g. The Mono project, which implements a runtime for running managed code on Android, Linux and OS X).

#954 – Static Typing vs. Strongly Typed

There is often confusion in C# between the terms static typing (or statically typed) and strongly typed.

Static typing is the process of enforcing type safety at compile-time, ensuring that you only interact with objects in ways that are allowed by that object’s type.  C# mostly uses static typing to enforce type safety, but also supports dynamic typing, using the dynamic keyword.

The idea of a language being strongly typed is, in general, the idea that a language enforces type safety.  This may be done either statically or dynamically.  People have traditionally considered C# to be a strongly typed language.

The term strongly typed is not all that useful, however.  The term is subjective and means different things to different people.  Different languages may be more or less strongly typed than other languages.  So it doesn’t make sense to say that a language is or is not strongly typed.

#953 – Static Typing vs. Dynamic Typing

C# enforces type safety in that it limits you to interacting with an object in ways that are allowed by that object’s type.

C# achieves type safety through the use of both static typing and dynamic typing.  (Also referred to as “static type-checking” and “dynamic type-checking”).

Static typing is the process of enforcing type safety at compile-time.  The compiler prohibits certain operations, based on the type of the objects involved.

For example:

Cat c = new Cat("Fluffy");

At compile-time, the compiler flags an error when we try to call the Bark method on our Cat object.


Most type safety is enforced in C# at compile-time (static typing).

Dynamic typing is the process of enforcing type safety at run-time, rather than compile-time.  Type-checking can be delayed until run-time by using the dynamic keyword.

// Compiles ok now, but fails at run-time
dynamic c = new Cat("Fluffy");


#952 – Type Safety

C# enforces type safety.  Type safety is the idea that you can only interact with an object in ways that are allowed by the object’s type.  You can’t treat an instance  of one type like it is actually an instance of another type.

Below is an example of some C++ code that is not type safe.  We use a pointer to treat a floating point value as an integer.  This results in an unexpected integer value.  This behavior is not normally something that you cannot do in C# (without marking the code as “unsafe”).

	double d1 = 1.1;

	void* ptr = &d1;    // Pointer to memory where double is stored
	int* ptr2 = (int*)ptr;   // Use the pointer as a pointer to int

	int n1 = *ptr2;     // Treat double as int


#951 – Not Every Type Derives from object

C# is normally said to have a Unified Type System, that is–every type derives from object (System.Object), directly or indirectly.

This is mostly true, but not completely accurate.

Most types do derive from object, including: classes, value types, and delegates.  And all object instances that you work with will be instances of types that do derive from object.  (Or they will have a null value).

But there are several types that do not derive from object, including:

  • interface – an interface is a type that does not derive from object.  Rather, an interface can be implemented by some type that does derive from object.
  • dynamic – dynamic is a type in that you can declare variables to be of type dynamic, but it is not an actual type in the CLR that derives from object (although its semantics are similar to the semantics of object)
  • System.TypedReference – does not derive from object