The ECMA standard lists these design goals for C#:

• C# is intended to be a simple, modern, general-purpose, object-oriented programming language.
• Because software robustness, durability, and programmer productivity are important, the language should include strong type checking, array bounds checking, detection of attempts to use uninitialized variables, Source code portability, and automatic garbage collection.
• The language is intended for use in developing software components that can take advantage of distributed environments.
• Programmer portability is very important, especially for those programmers already familiar with C and C++.
• Support for internationalization is very important.
• C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions.
• Although C# applications are intended to be economical with regards to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

Architectural history

C#'s principal designer and lead architect at Microsoft is Anders Hejlsberg. His previous experience in programming language and framework design (Visual J++, Borland Delphi, Turbo Pascal) can be readily seen in the syntax of the C# language, as well as throughout the Common Language Runtime (CLR) core. In interviews and technical papers he has stated flaws in most major programming languages, C++, Java, Delphi, Smalltalk, drove the fundamentals of the CLR, which, in turn, drove the design of the C# programming language itself. Some argue that C# shares roots in other languages, as purported by the programming language history chart.

By design, C# is the programming language that most directly reflects the underlying Common Language Infrastructure (CLI). Most of C#'s intrinsic types correspond to value-types implemented by the CLI framework. However, the C# language specification does not state the code generation requirements of the compiler: that is, it does not state that a C# compiler must target a Common Language Runtime (CLR), or generate Common Intermediate Language (CIL), or generate any other specific format. Theoretically, a C# compiler could generate machine code like traditional compilers of C++ or FORTRAN; in practice, all existing C# implementations target CLI.

C# differs from C and C++ in many ways, including:

• There are no global variables or functions. All methods and members must be declared within classes.
• Local variables cannot shadow variables of the enclosing block, unlike C and C++. Variable shadowing is often considered confusing by C++ texts.
• C# supports a strict boolean type, bool. Statements that take conditions, such as while and if, require an expression of a boolean type. While C and C++ also have a boolean type, it can be freely converted to and from integers, and expressions such as if(a) require only that a is convertible to bool, allowing a to be an int, or a pointer. C# disallows this 'integer meaning true or false' approach on the grounds that forcing programmers to use expressions that return exactly bool prevents certain types of programming mistakes.
• In C#, pointers can only be used within blocks specifically marked as unsafe, and programs with unsafe code need appropriate permissions to run. Most object access is done through safe references, which cannot be made invalid. An unsafe pointer can point to instance of a value-type, array, string, or a block of memory allocated on a stack. Code that is not marked as unsafe can still store and manipulate pointers through the System.IntPtr type, but cannot dereference them.
• Managed memory cannot be explicitly freed, but is automatically garbage collected. Garbage collection addresses memory leaks. C# also provides direct support for deterministic finalization with the using statement (supporting the Resource Acquisition Is Initialization idiom).
• Multiple inheritance is not supported, although a class can implement any number of interfaces. This was a design decision by the language's lead architect to avoid complication, avoid "dependency hell," and simplify architectural requirements throughout CLI.
• C# is more typesafe than C++. The only implicit conversions by default are safe conversions, such as widening of integers and conversion from a derived type to a base type. This is enforced at compile-time, during JIT, and, in some cases, at runtime. There are no implicit conversions between booleans and integers and between enumeration members and integers (except 0, which can be implicitly converted to an enumerated type), and any user-defined conversion must be explicitly marked as explicit or implicit, unlike C++ copy constructors (which are implicit by default) and conversion operators (which are always implicit).
• Enumeration members are placed in their own namespace.
• Accessors called properties can be used to modify an object with syntax that resembles C++ member field access. In C++, declaring a member public enables both reading and writing to that member, and accessor methods must be used if more fine-grained control is needed. In C#, properties allow control over member access and data validation.
• Full type reflection and discovery is available.

Unified type system

C# has a unified type system. This means that all types, including primitives such as integers, are subclasses of the System.Object class. For example, every type inherits a ToString() method. For performance reasons, primitive types (and value types in general) are internally allocated on the stack. Boxing and unboxing allow one to translate primitive data to and from their object form. Effectively, this makes the primitive types a subtype of the Object type. Primitive types can also define methods (e.g., 42.ToString() calls the ToString() method on an integer), and in the programmer's perspective behave like any other object.

C# allows the programmer to create user-defined value types, using the struct keyword. From the programmer's perspective, they can be seen as lightweight classes. Unlike regular classes, and like the standard primitives, such value types are allocated on the stack rather than on the heap. They can also be part of an object (either as a field or boxed), or stored in an array, without the memory indirection that normally exists for class types. Structs also come with a number of limitations. Because structs have no notion of a null value and can be used in arrays without initialization, they always come with an implicit default constructor that essentially fills the struct memory space with zeroes. The programmer can only define additional constructors with one or more arguments. This also means that structs lack a virtual method table, and because of that (and the fixed memory footprint), they cannot allow inheritance (but can implement interfaces).