The first thing to note about strings in .NET is that they are Reference Types. Reference types are live on the managed heap in .NET and so they are managed by the .NET Garbage Collector and unlike Value types they are not automatically destroyed when they are out of scope.

Strings can be easily instantiated using the below syntax:

string s1;

Note that there is no default value for a string, thus you need to assign a value to the string before attempting to access it:

string s1;
Literal1.Text = s1; //Will give run-time error 

string s2 = ""; //This is as close as you can get to assigning nothing to a string;
Literal1.Text = s2;

There are numerous inbuilt methods in the .NET framework for dealing with strings. Namely:

Note that strings are immutable and thus the original string can never be changed. Therefore if you need to alter the string you will need to re-assign it a new string value:

string s1 = "all lower case";
s1.ToUpper() ; //s1 is unchanged
Literal1.Text = s1;  //outputs 'all lower case' since s1 is unchanged

string s2 = "all lower case";
s2 = s2.ToUpper() ; //s2 is now re-assigned the new uppercase string
Literal2.Text = s2; //outputs 'ALL LOWER CASE'

For more on string immutability see Strings are Immutable.

String Concatenation

C# offers a convenient method for concatenating a string using ‘+’ :

string s1 = "Hong ";
string s2 = "Kong";
Literal1.Text = s1 + s2;

Whilst this method is convenient it is not efficient for performing a large number of concatenations (since strings are immutable and are refenece types created on the managed heap each concatenation results in the creation of an extra string which is not automatically destroyed and stays in memory until the Garbage Collector destroys it).

To get around this limitation the .NET Framework provides the StringBuilder class which can efficiently concatenate strings using its Append() method:

 StringBuilder sb = new StringBuilder();
 sb.Append("Hong ");
 sb.Append("Kong");

Literal1.Text = sb.ToString();

This is by way of demonstration since there would not be any memory saving from concatentating two strings (in fact this can consume more memory since the StringBuilder consumes memory). In general concatenating more than four strings is normally when a StringBuilder should be used.

Escape Characters

In common with other C-based languages, C# strings may contain escape characters which qualify how the string should be output.
Escape characters begin with a backslash followed by a specific character.

Below are listed the various escape characters and their output:

\’ Inserts a single quote
\” Inserts a double quote
\\ Inserts a backslash
\a Triggers a system alert
\n Inserts a new line (on Windows systems)
\r Inserts a carriage return
\t Inserts a horizontal tab

Verbatim Strings

To preserve a string exactly as it is exactly as it was added simply add the @ character at the start of the string.

For example:

string outputStr =   "This site is named \'C# Help\'  ";
Response.Write(outputStr);

This outputs

This site is named 'C# Help'

To output the string verbatim add the @ character at the start of the string.

string outputStr =   @"This site is named \'C# Help\'  ";
Response.Write(outputStr);

This outputs

This site is named \'C# Help\'

Note that this will also preserve white space:

string outputStr =   @"This is a                  broken
up
             string";  

Regular Parameter Passing

This is passing parameters with no modifying keywords :

 void MyMethod(Student studentObj, int aNumber)
    {
        aNumber += 5;
        studentObj.Name = "Jon";
    }

In the above example MyMethod takes two parameters – a Student object and an Integer. Note the difference between the passing a Value Type (such as an Integer) and a Reference Type (such as any class such as a ‘Student’ object in the above example). Any operations performed on a value type will no be reflected in the original variable whereas operations performed on a reference type are reflected in the original variable. For example, assuming calling the above MyMethod method note the below code (note the comment explanation at the end of the code block):

int myInt = 8;
Student aStudent = new Student();
aStudent.Name = "Mike";

MyMethod(aStudent, myInt);
// myInt value is still 8 since it is a Value Type and immutable
// aStudent.Name is now Jon since it is a Reference Type
// and the variable aStudent just points to a Student object
// on the Managed Heap which is then operated upon by the MyMethod(0 method.

Parameter Passing By Reference

By default all paramteres are passed by value – i.e. only the value of the variable is passed to method and the object itself is not passed. Thus operations within the method can only operate on the value of the parameter it receives and cannot make changes to the original variable (do note that this only applies to Value Types as noted above since Reference Types will have their state changes when they are passed to methods).
Alternatively, parameters can be passed by Reference using the ref keyword and their values will be changed by the method:

   void MyMethod(ref int aNumber)
    {
        aNumber += 5;
    }

    protected void Page_Load(object sender, EventArgs e)
    {
      int myInt = 8;
      MyMethod(ref myInt);
      //myInt is now 13
    }

In the above code the aNumber parameter in MyMethod now has the ref keyword, note that the ref keyword is always required when calling the method.
The integer which is passed to the method now has its value changed by the method.

Parameter Passing Using the out Keyword

The out keyword has a similar impact to the ref keyword as the parameters that are passed to it can have their values changed.
The primary difference is that when using the out keyword the objects do not need to be initialized. In the above example of passing by reference there would be a compile-time error if the integer had simply been declared by not initialized with a value as below:

 int myInt;

If the ref keyword was replaced with the out keyword this issue would be resolved:

    void MyMethod(out int aNumber)
    {
        aNumber = 3;
        aNumber += 5;
    }

    protected void Page_Load(object sender, EventArgs e)
    {
      int myInt;
      MyMethod(out myInt);
      //myInt is now 8
	}

Note that the integer is now initialized with a value in the method body.

You might wonder what is the point of the out keyword. It can be very useful in situations where you want a method to perform several operations and return multiple values. In this circumstance you can simply declare multiple variables and pass them to void method to have their values assigned.

The String.Format method is very flexible and can be used to apply custom formatting rules. The # character informs the Format method how to format the numerical value, for example to forma the number 12000.12 as 12,000.12 use can use the format “#,#.##” as in the below code:

double dbl1 = 12000.12;
string outputStr;
outputStr = string.Format("This is a custom formatting example  {0:#,#.##} ", dbl1);
Response.Write(outputStr);

In this example the , character is used to denote the thousand separator and the ## after the decimal place denotes that a maximum of 2 numbers should appear after the decimal place. Therefore the double 12000.1 would be formatted as 12,000.1, if you wish two decimals places always to be shown (ie 12,100.10 in this case) you should use the ’0′ character after the decimal place:

outputStr = string.Format("This is a custom formatting example  {0:#,#.00} ", 12000.1);

You can also add additional characters before and after the formatting string. Thus to format the value as $ 12,000.12 use the format string “$ #,#.##” , or even “#,#.## US Dollars” would output “12,000.12 US Dollars”.

The % character will multiply the value by 100 and then add % character to the end of the string. Thus for the double value 12 the format string “{0:0.00 %}” will output “1200.00 %”. Note that you can use the # character in place of the 0 character as per the formatting rules above and so “#,#.## %” in this case would output “1,200 %”.

double dbl1 = 9999999.9999999;
outputStr = string.Format("This is the currency format {0:c}", dbl1);

This will output the numerical value as a currency based on the user’s current currency setting. In my case this will output:

This is the currency format $10,000,000.00

Note firstly that String.Format is a static method – ie you can not use it from an instance of a string object so the below code will generate a compile error:

string outputStr;
outputStr.Format("This is the currency format {0:c}", dbl1);

You must always use it at the class level (ie String.Format)

Below are the inbuilt formatting specifiers:
c – Currency
d – Decimal
e – Exponential notation
f – Fixed point formatting
n – Numerical formatting (with commas)
x – Hexidecimal

The below code shows an implementation of the n formatting speficier:

double dbl1 = 9999999.9999999;
string outputStr;
outputStr = string.Format("This is the numerical format {0:n}", dbl1);
Response.Write(outputStr);

This outputs

This is the numerical format 10,000,000.00

Note that there will be compile errors if you attempt to format a double using the decimal format. Also, note that hexidecimal expects an integer type.

Immutable simply means that once created it doesn’t change. This seems strange at first since the value of a string variable can indeed be altered :

string s1 = "Initial Value";
s1 = "Updated Value";
Literal1.Text = s1;

In the above code the Literal will output the text “Updated Value” which seems to demonstrate the String s1 has been changed. However, behind the scenes a new object has actually been created by the .NET Framework and the variable s1 has been pointed to that (note the the original string object is still held in memory until the Garbage Collection is automatically run by the .NET Framework and so working with strings can consume a lot of memory if care isn’t taken).

The impact of strings being immutable is normally felt when manipulating them through the methods provided in the Framework:

string s1 = "Initial Value";
s1.ToUpper();
Literal1.Text = s1;

In the above snippet, we may think calling ToUpper() should convert the string to upper case and so the Literal should output “INITIAL VALUE” but instead the output is still “Initial Value”. A string is immutable! It cannot be changed, all the method ToUpper() does is return a new string of upper case values for the s1 string. The original string (s1 in this case is left unchanged).
To alter the actual string we will need to reassign its value:

string s1 = "Initial Value";
s1 = s1.ToUpper();
Literal1.Text = s1;

This results in the expected output of uppercase.

Note that the same holds true all the common methods of string manipulation such as Replace(), Remove(), Trim(), Insert().

For example, the below code will leave the original string s1 totally unchanged:

string s1 = "Initial xx";
s1.Replace("xx", "Value");
Literal1.Text = s1;

Instead it needs to be rewritten:

string s1 = "Initial xx";
s1 = s1.Replace("xx", "Value");
Literal1.Text = s1;

Note that it is  more efficient from both a code and memory perspective to leave the original string unaltered and simply output the new string values as required:

string s1 = "Initial xx";
Literal1.Text = s1.Replace("xx", "Value");

Hope this helps clarify a common issue in handling strings in .NET.

System.Diagnostics.Stopwatch timerObj = new System.Diagnostics.Stopwatch();
timer.Start();
Decimal totalDec = 0;
int limit = 1000000;
for (int i = 0; i < limit; ++i)
{
totalDec = totalDec + (Decimal)Math.Sqrt(i);
}
timerObj.Stop();
Console.WriteLine(“Sum of square roots: {0}”,totalDec);
Console.WriteLine(“Milliseconds elapsed : {0}”,
timerObj.ElapsedMilliseconds);
Console.WriteLine(“Time elapsed : {0}”, timerObj.Elapsed);

This outputs the below:
Sum of square roots : 666666166.45882210823608
Milliseconds elapsed: 282
Time elapsed : 00:00:00.2828692

When using the Stopwatch for debugging you can to utilize the IDisposable interface to automate the stopwatch:

class AutoStopwatchDemo : System.Diagnostics.Stopwatch, IDisposable
{
public AutoStopwatchDemo()
{
Start();
}
public void Dispose()
{
Stop();
Console.WriteLine(“Elapsed : {0}”, this.Elapsed);
}
}

Now, you can use {} syntax:

using (new AutoStopwatchDemo())
{
Decimal totalObj2 = 0;
int limitObj2 = 1000000;
for (int i = 0; i < limit2; ++i)
{
totalObj2 = limitObj2  + (Decimal)Math.Sqrt(i);
}
}

Besides the Stopwatches Start() and Stop() methods, there is also Reset(), which stops the timer and then sets Elapsed to 0. In addition there is also the Restart() method, which sets Elapsed to 0 but the timer continues to run.

Unless there is a good reason not to, you should always select Any CPU see below:

Since .NET assemblies consist of byte code that is  JIT (just-in-time) compiled to the current platform at runtime, an app’s assemblies will function on any architecture without needing to rebuild from the source code.

However, the choice is not always that simple. If your .NET assembly references or interops with another managed assembly or an unmanaged DLL which was compiled for a certain architecture, then your app’s .NET assembly will need to match the assembly or dll’s.

Take for example a scenario where you  have the following:

• .NET assembly: Any CPU
• 32-bit COM component

On a 32-bit OS this scenario will work fine since the .NET assembly will be JIT  compiled as 32 bits. However, this will fail on a 64-bit OS since the .NET assembly will be 64 bits and when it attempts to call into the COM component the app will break. In such a scenario, it best to specify that the assembly should always be 32 bit.

Note that x64 OSs  run 32-bit processes just fine. Also bear in  mind  that while .NET itself mostly insulates you from platform architecture considerations, when you using unsafe code, pointers, or relying on the size of IntPtr, you will likely encounter issues when running on multiple architectures.

__declspec(dllexport) int Hello(char* pszBuffer, int nLengthObj);

MyLib.cpp

#include “stdafx.h”
#include “MyLib.h”
#include
__declspec(dllexport) int SayHello(char* pszBuffer, int nLengthObj)
{
::strcpy_s(pszBuffer, nLength, “Hello, from the C++ DLL”);
return strlen(pszBuffer);
}
LIBRARY “MyLib”
EXPORTS
Hello

From C#, calling this function is relatively simple. The below code shows this as well as when calling a method that takes char* you first need to convert the string to bytes.

[DllImport(“MyLib.dll”, ExactSpelling=false,
CallingConvention=CallingConvention.Cdecl, EntryPoint=”Hello”)]
public static extern int Hello(
[MarshalAs(UnmanagedType.LPArray)] byte[] buffer,int length);
static void Main(string[] args)
{
int size = 32;
//we need to manually marshal the bytes to a String
byte[] buffer = new byte[size];
int returnVal = Hello(buffer, size);
string result = Encoding.ASCII.GetString(buffer,0, returnVal);
Console.WriteLine(“”{0}”, return value: {1}”, result, returnVal);
}

Retrieve Your App’s Memory Utilization using the GC class

The .NET Framework’s GC class contains many useful memory-related methods, including GetTotalMemory(), which returns the amount of memory the garbage collector believes is allocated to your app. The number not be exact right since some objects may not have been garbage collected yet. This, however does have the advantage of being able to inform you of the amount of memory a certain part of your app uses, as opposed to the entire process:

long memAvailable = GC.GetTotalMemory(false);
Console.WriteLine(“Before allocations: {0:N0}”, memAvailable);

int allocSizeObj = 40000000;
byte[] bigArrayObj = new byte[allocSizeObj];

memAvailable= GC.GetTotalMemory(false);
Console.WriteLine(“After allocations: {0:N0}”, memAvailable);

The above code will output the following:

Before allocations: 651,064
After allocations: 40,690,080

Retrieve Your App’s Memory Utilization using System.Diagnostics

You can also request the OS report on info about your process using the Process class  in the System.Diagnostics namespace:

Process procObj = Process.GetCurrentProcess();
Console.WriteLine(“Process Info: “+Environment.NewLine+
“App's Private Memory Size : {0:N0}”+Environment.NewLine +
“App's Virtual Memory Size : {1:N0}” + Environment.NewLine +
“App's Working Set Size: {2:N0}” + Environment.NewLine +
“App's Paged Memory Size: {3:N0}” + Environment.NewLine +
“App's Paged System Memory Size: {4:N0}” + Environment.NewLine +
“App's Non-paged System Memory Size: {5:N0}” + Environment.NewLine,
procObj.PrivateMemorySize64,
procObj.VirtualMemorySize64,
procObj.WorkingSet64,
procObj.PagedMemorySize64,
procObj.PagedSystemMemorySize64,
procObj.NonpagedSystemMemorySize64 );

Here’s the output:

Process Info:
Private Memory Size: 75,935,744
Virtual Memory Size: 590,348,288
Working Set Size: 29,364,224
Paged Memory Size: 75,935,744
Paged System Memory Size: 317,152
Non-paged System Memory Size: 37,388

These numbers are not necessarily intuitive, and you can consult a good operating system book, such as Windows Internals from Microsoft Press for more on how virtual memory works. Performance counters can also be used to track this as well as other info on your app or its environment.

static dynamic Mean (dynamic xObj, dynamic yObj)
{
return (xObj + yObj) / 2;
}
static void Main()
{
int xObj = 3, yObj = 4;
Console.WriteLine (Mean (xObj, yObj));
}

The benefit here is clear — you can avoid duplicating code for each numeric type. However, in doing so you will lose static type safety, risking runtime exceptions as opposed to getting compile time errors.
Note that dynamic binding only circumvents static type safety, runtime type safety is still perserved. In contrast when using reflection, you cannot circumvent member accessibility rules using dynamic binding.

Language runtime binding behaves very similarly to static binding when the runtime types of the dynamic objects are known at compile time. In the above example, the behavior of the program would be identical if Mean was hardcoded to work with the int type.