string and String are not the same thing in C# ?

In C# the string keyword (highlighted in Visual Studio as a data type) is just a shortcut to the String class right?

In that case, it would be the same to use either while coding from the semantic point of view. However, is it the same from the performance point of view? I mean, when the mapping is performed: during compilation (I guess so), during compilation or during JIT compilation in execution?

Or maybe this is all wrong: string and String are not the same thing in C# so there are some situations where they cannot be interchanged

Here’s a brain dump of related information…

As others have noted, string is an alias for System.String. They compile to the same code, so at execution time there is no difference whatsoever. This is just one of the aliases in C#. The complete list is:

	object: System.Object

	string: System.String

	bool: System.Boolean

	byte: System.Byte

	sbyte: System.SByte

	short: System.Int16

	ushort: System.UInt16

	int: System.Int32

	uint: System.UInt32

	long: System.Int64

	ulong: System.UInt64

	float: System.Single

	double: System.Double

	decimal: System.Decimal

	char: System.Char

Apart from string, object, the aliases are all to value types. decimal is a value type, but not a primitive type in the CLR. The only primitive type which doesn't have an alias is System.IntPtr.

In the spec, the value type aliases are known as "simple types". Literals can be used for constant values of every simple type; no other value types have literal forms available. (Compare this with VB, which allows DateTime literals, and has an alias for it too.)

There is one circumstance in which you have to use the aliases: when explicitly specifying an enum's underlying type. For instance:

public enum Foo : UInt32 {} // Invalid
public enum Bar : uint {} // Valid

Finally, when it comes to which to use: personally I use the aliases everywhere for the implementation, but the CLR type for any APIs. It really doesn't matter too much which you use in terms of implementation - consistency among your team is nice, but no-one else is going to care. On the other hand, it's genuinely important that if you refer to a type in an API, you do so in a language neutral way. A method called "ReadInt32" is unambiguous, whereas a method called "ReadInt" requires interpretation. The caller could be using a language which defines an "int" alias for Int16, for example. The .NET framework designers have followed this pattern, good examples being in the BitConverter, BinaryReader and Convert classes.