static void Main(string[] args)
{
	AppDomain.CurrentDomain.FirstChanceException += (sender, eventArgs) =>
	{
		Console.WriteLine("First chance exception: " + eventArgs.Exception.Message);
	};

	try 
	{
		Console.WriteLine("Before exception.");
		throw new Exception("Some error.");
	}
	catch
	{
		Console.WriteLine("Handled.");
	}
}

This code will produce the output:

Before exception.
First chance exception: Some error.
Handled.

However, if an exception is thrown within the event handler, the FirstChanceException event will be raised recursively. The code below will cause a stack overflow:

static void Main(string[] args)
{
	AppDomain.CurrentDomain.FirstChanceException += (sender, eventArgs) =>
	{
		try
		{
			throw new Exception();
		}
		catch
		{
		}
	};

	try 
	{
		throw new Exception();
	}
	catch
	{
	}
}

This is important to remember if we use any third party libraries, such as a logging library like Log4Net, to log exceptions within the event handler. These third party libraries may throw an exception internally, which will cause the FirstChanceException event to be raised recursively. Even without the use of third party libraries, any code may unexpectedly thrown an exception, which will cause the event to be raised recursively and cause a stack overflow. The MSDN documentation mentions this fact:

You must handle all exceptions that occur in the event handler for the FirstChanceException event. Otherwise, FirstChanceException is raised recursively. This could result in a stack overflow and termination of the application. We recommend that you implement event handlers for this event as constrained execution regions (CERs), to keep infrastructure-related exceptions such as out-of-memory or stack overflow from affecting the virtual machine while the exception notification is being processed.

Unfortunately, the documentation doesn’t provide any code samples. I haven’t been able to figure a way to prevent stack overflows without resorting to a somewhat non-elegant solution. What we can do is check to see if the event handler is found multiple times in the current stack trace. If it is, we can immediately return to prevent the event from being raised again.

static void Main(string[] args)
{
	AppDomain.CurrentDomain.FirstChanceException += (sender, eventArgs) =>
	{
		StackFrame[] frames = new StackTrace(1).GetFrames();
		MethodBase currentMethod = MethodBase.GetCurrentMethod();

		if (frames != null && frames.Any(x => x.GetMethod() == currentMethod))
			return;

		throw new Exception();
	};

	throw new Exception();
}

Instantiating StackTrace may throw an ArgumentOutOfRangeException if the parameter is negative, which is not what we’re doing here. The GetFrames() method may return null, so the if condition needs to check for null. The GetCurrentMethod() method may throw a TargetException if the method was invoked with a late-binding mechanism, which is not what we’re doing here.

The code above should be relatively safe and should prevent a stack overflow if an exception is thrown within the event handler.

public static class SystemTime
{
    public static Func<DateTime> Now = () => DateTime.Now;
}

We may use SystemTime.Now() anywhere in our code instead of DateTime.Now. This will allow us to control time in a deterministic fashion in order to keep our tests consistent. However, one of the downsides is that we have to remember to reset the time after each test.

[TestMethod]
public void DemoTest()
{
    SystemTime.Now = () => new DateTime(1970, 1, 1);
            
    // Test code...

    SystemTime.Now = () => DateTime.Now;
}

We can ease the pain by implementing this as part of the tear down process that runs after each test. I think that’s an acceptable solution, but I still prefer all my test code to be as close together as possible. The tear down process may also run for tests that don’t deal with SystemTime.Now(), so that’s extra overhead for nothing.

Instead, I decided to add a few additions to SystemTime:

public class SystemTime : IDisposable
{
    private static Func<DateTime> now = () => DateTime.Now;

    public static DateTime Now
    {
        get { return now(); }
    }

    private SystemTime()
    {
    }

    public static SystemTime Context(DateTime dateTime)
    {
        now = () => dateTime;
        return new SystemTime();
    }

    public void Dispose()
    {
        now = () => DateTime.Now;
    }
}

I changed the Now property to type DateTime instead of Func<DateTime> so that it more closely resembles DateTime.Now. Implementing IDisposable gives us an easy way to reset SystemTime.Now.

[TestMethod]
public void DemoTest()
{
    using (SystemTime.Context(new DateTime(1970, 1, 1)))
    {
        // Test code...
    }
}

To demonstrate, we can run this code:

Console.WriteLine(SystemTime.Now);

using (SystemTime.Context(new DateTime(1970, 1, 1)))
{
    Console.WriteLine(SystemTime.Now);
}

Console.WriteLine(SystemTime.Now);

The output is:

5/9/2012 2:21:08 AM
1/1/1970 12:00:00 AM
5/9/2012 2:21:08 AM

<link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="@Url.Content("~/Scripts/jquery.js")"></script>

While in development, I would like the resources to point to the local versions. In production, the resources should point to our CDN. I also want the ability to switch to the local versions if there is a problem with our CDN.

I’ve added two AppSettings keys to the web.config:

<add key="CDN.Enabled" value="true" />
<add key="CDN.Address" value="http://cdn.example.com/" />

If we need to switch to local versions, we can flip CDN.Enabled to false. Instead of using the default Url.Content() helper, we’ll update the views to use our own Url.ContentFromCdn() helper.

<link href="@Url.ContentFromCdn("~/Content/Site.css")" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="@Url.ContentFromCdn("~/Scripts/jquery.js")"></script>

Here is the code for the helper:

public static class UrlHelpers
{
    public static string ContentFromCdn(this UrlHelper helper, string contentPath)
    {
        bool cdnEnabled;

        Boolean.TryParse(
            ConfigurationManager.AppSettings["CDN.Enabled"],
            out cdnEnabled);

        if (!cdnEnabled)
            return helper.Content(contentPath);
            
        var baseUri = new Uri(ConfigurationManager.AppSettings["CDN.Address"]);
        var content = VirtualPathUtility.ToAbsolute(contentPath);

        return new Uri(baseUri, content).AbsoluteUri;
    }
}

The helper will fall back to the default Url.Content() helper if the CDN.Enabled setting evaluates to false. If we need to use Google’s CDN (or any other public CDN), we can use a dictionary to look for specific filenames and return a specific address.

public static class UrlHelpers
{
    private static Dictionary<string, string> cdn = 
        new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
        {
            { "jquery.js", "https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.js" },
            { "jquery-ui.js", "https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.js" }
        };

    public static string ContentFromCdn(this UrlHelper helper, string contentPath)
    {
        bool cdnEnabled;

        Boolean.TryParse(
            ConfigurationManager.AppSettings["CDN.Enabled"],
            out cdnEnabled);

        // Use default Url.Content() helper.
        if (!cdnEnabled)
            return helper.Content(contentPath);

        var fileName = VirtualPathUtility.GetFileName(contentPath);

        // Use public CDN address for this file.
        if (cdn.ContainsKey(fileName))
            return cdn[fileName];
            
        var baseUri = new Uri(ConfigurationManager.AppSettings["CDN.Address"]);
        var content = VirtualPathUtility.ToAbsolute(contentPath);

        return new Uri(baseUri, content).AbsoluteUri;
    }
}

public class Demo
{
	private static Expensive expensive = new Expensive();

	public static void Start() 
	{
	}

	public static void UseExpensive()
	{
		expensive.DoSomething();
	}
}

internal class Expensive
{
	public Expensive()
	{
		// Expensive operation
	}

	public void DoSomething()
	{
	}
}

The Demo class uses field initialization to create an instance of the Expensive class. The Start method does not use any of the static fields.

The WinForm application calls Demo.Start() in the constructor and Demo.UseExpensive() in a button event.

public partial class SomeForm : Form
{
	public SomeForm()
	{
		InitializeComponent();

		Demo.Start();
	}

	private void button_Click(object sender, EventArgs e)
	{
		Demo.UseExpensive();
	}
}

In .NET 2.0, the constructor of the Expensive class would execute on application start-up. In .NET 4.0 however, the constructor of the Expensive class would not execute until the button event was fired. Since the Expensive class is costly to create due to various operations in the constructor, the button event in .NET 4.0 was noticeably slower on the first click.

The reason is due to how .NET initializes types that contain static fields and/or a static constructor. If a type does not contain a static constructor, it will be marked with the BeforeFieldInit flag.

Using ILSpy to decompile into IL, we can see the current class marked with BeforeFieldInit:

If we include a static constructor (even if it’s empty), we’ll see that the class is no longer marked with BeforeFieldInit:

When marked with BeforeFieldInit in .NET 2.0, static field initialization may occur at any time before a static field is used. This means that static field initialization may occur even if a static field is never used. When marked with BeforeFieldInit in .NET 4.0, static field initialization only occurs before a static field is used. To demonstrate, we can use a console application to see when events occur.

class Program
{
	static void Main(string[] args)
	{
		Console.WriteLine("Started.");
		Demo.Start();
		Console.WriteLine("End.");
	}
}

public class Demo
{
	private static ExpensiveClass expensive = new ExpensiveClass();

	public static void Start()
	{
		Console.WriteLine("In Start method.");
	}

	public static void UseExpensive()
	{
		Console.WriteLine("In UseExpensive method.");
		expensive.DoSomething();
	}
}

internal class ExpensiveClass
{
	public ExpensiveClass()
	{
		Console.WriteLine("In ExpensiveClass constructor.");
	}

	public void DoSomething()
	{
	}
}

The console application is calling Demo.Start() in the Main method, which does not reference any static fields. The output in .NET 2.0 is:

In ExpensiveClass constructor.
Started.
In Start method.
End.

The output in .NET 4.0 is:

Started.
In Start method.
End.

Although the Demo.Start() method never references any static fields, static field initialization occurs anyway in .NET 2.0.

We can force static field initialization to occur in .NET 4.0 by adding a call to Demo.UseExpensive(), which does reference a static field.

static void Main(string[] args)
{
	Console.WriteLine("Started.");
	Demo.Start();
	Demo.UseExpensive();
	Console.WriteLine("End.");
}

The output in .NET 4.0 is:

Started.
In Start method.
In ExpensiveClass constructor.
In UseExpensive method.
End.

As you can see, static field initialization does not occur in .NET 4.0 until a static field is first referenced.

If we update the Demo class and add an empty static constructor, the class will no longer be marked with BeforeFieldInit. If a type isn’t marked with BeforeFieldInit, static field initialization will occur before any class member is used.

class Program
{
	static void Main(string[] args)
	{
		Console.WriteLine("Started.");
		Demo.Start();
		Console.WriteLine("End.");
	}
}

public class Demo
{
	public static ExpensiveClass expensive = new ExpensiveClass();

	static Demo()
	{
	}

	public static void Start()
	{
		Console.WriteLine("In Start method.");
	}

	public static void UseExpensive()
	{
		Console.WriteLine("In UseExpensive method.");
		expensive.DoSomething();
	}
}

The output for .NET 2.0 and .NET 4.0 will be identical:

Started.
In ExpensiveClass constructor.
In Start method.
End.

• http://www.codeproject.com/Tips/197531/Do-not-use-using-for-WCF-Clients
• http://geekswithblogs.net/DavidBarrett/archive/2007/11/22/117058.aspx
• http://ardalis.com/idisposable-and-wcf

To summarize, the Close() method will be called when the WCF client is disposed. However, if we try to dispose the client while it’s in a faulted state, an exception will be thrown.

The extension method provided in the CodeProject article allows you do something like this:

new MyTestClient().Using(x => x.DoSomething());

The Using() extension method will automatically close or abort the client once finished. However, I do not like this extension method. Without any explanation, a developer may mistakenly reuse the client:

var client = new MyTestClient();
client.Using(x => x.DoSomething());
client.Using(x => x.DoSomething());  // Connection is already closed.

Instead, I use this class:

public static class Client
{
    public static void Use<TClient>(Action<TClient> action)
        where TClient : ICommunicationObject, new()
    {
        var client = new TClient();

        try
        {
            action(client);
            client.Close();
        }
        catch (Exception)
        {
            client.Abort();
            throw;
        }
    }
}

… and the usage:

Client.Use<MyTestClient>(x => x.DoSomething());

One problem with the class above is that if we needed to instantiate the client using one of the overloaded constructors, we couldn’t due to the new() constraint. Instead, we can use this class:

public class Client<TClient>
    where TClient : ICommunicationObject
{
    private readonly TClient client;

    private Client(TClient client)
    {
        this.client = client;
    }

    public static Client<TClient> Instantiate(Func<TClient> action)
    {
        return new Client<TClient>(action());
    }

    public void Use(Action<TClient> action)
    {
        try
        {
            action(client);
            client.Close();
        }
        catch (Exception)
        {
            client.Abort();
            throw;
        }
    }
}

… and the usage:

Client<MyTestClient>
    .Instantiate(() => new MyTestClient("extra param"))
    .Use(x => x.DoSomething());

protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        if (!HasPermissions())
            HideSensitiveFields();
    }
}

The code here checks if this is a normal page load and not a postback. If this is the initial page load, it’ll check if the user may see sensitive (administrative) fields and hides them if the user does not have the appropriate permissions.

The problem is that it assumes all initial page loads will enter the !IsPostBack conditional block. Postback can be faked by passing in a few select query strings, such as __EVENTTARGET.

This problem can be solved using event validation, encrypted viewstate, and other better coding practices, but that’s a different subject and I won’t dive into those in this post.

http://localhost:8080/Default.aspx?__eventtarget=

By default, ASP.NET doesn’t check the HTTP verb, so we can pass a few select query string parameters and essentially spoof a postback. The URL above would bypass the !IsPostBack conditional block, allowing access to the sensitive fields.

For those that are unfamiliar with Moles, it was an isolation framework that allowed us to replace dependencies in our unit tests. For example, if our legacy code uses the static method Util.GetUser() to retrieve information from a database, there isn’t an easy way to change or remove that behavior. Moles allowed us to intercept the call to Util.GetUser() and redirect it to our own implementation. This is important because we want to keep our unit tests isolated, free from external dependencies such as the database. Keeping the results deterministic is also a good way to ensure that our test results are consistent.

The Fakes Framework introduces two types of fakes: stubs and shims. Stubs allow us to replace a method with our own implementation for interfaces and virtual methods. Shims allow us to override methods that usually can’t be overridden, such as static methods and non-virtual methods. Shims also allow us to intercept calls to types found in the .NET base class library.

public class AuthenticationService
{
    private readonly IUserRepository repository;

    public AuthenticationService(IUserRepository repository)
    {
        this.repository = repository;
    }

    public bool Authenticate(string username, string password)
    {
        User user = repository.GetUser(username);
        return user.Password == password;
    }
}

For our test, we want to make sure that Authenticate() returns false when the password does not match what’s returned from the repository. The AuthenticationService requires an instance of IUserRepository. We can use a stub to replace the method call GetUser().

The Fakes Framework will generate strongly typed fakes for each assembly that we want to fake. For stubs, each type will be prefixed with Stub. In the test below, we’ll be using the stub StubIUserRepository, which is an implementation of the interface IUserRepository. Each method/property on the stubbed type will contain delegates that are named very similar to the original method/property. We can change the implementation of the method GetUser() by assigning a delegate to the GetUserString field on the stubbed type.

[TestMethod]
public void Demo()
{
    var repository = new StubIUserRepository();

    repository.GetUserString = 
        username => new User { Name = "Malvin", Password = "secret" };

    var service = new AuthenticationService(repository);
    var isAuthenticated = service.Authenticate("Malvin", "password");

    Assert.IsFalse(isAuthenticated);
}

When GetUser() is called from AuthenticationService, the repository will return our hard-coded User with the name “Malvin” and password “secret”.

However, there are cases when it isn’t possible to replace the repository:

public class AuthenticationService
{
    public bool Authenticate(string username, string password)
    {
        UserRepository repository = new UserRepository();

        User user = repository.GetUser(username);

        return user.Password == password;
    }
}

Let’s assume that we want to run the same test again. Instead of using stubs, we’ll use a shim to intercept the call to GetUser().

The Fakes Framework will generate strongly typed shims for each type in the original assembly. Each type are prefixed with Shim. Before we can use shims, we must create a new context under which the shims will be active.

In our test, we are specifying that for all calls to GetUser() for any instance of UserRepository while inside the ShimContext, we want to intercept that call and return our own User.

[TestMethod]
public void Demo()
{
    using (ShimsContext.Create())
    {
        ShimUserRepository.AllInstances.GetUserString =
            (repository, username) => new User { Name = "Malvin", Password = "secret" };

        var service = new AuthenticationService();
        var isAuthenticated = service.Authenticate("Malvin", "password");

        Assert.IsFalse(isAuthenticated);    
    }
}

For cases where we may not want to override the behavior for all instances of a type, we can create individual instances:

var repository = new ShimUserRepository();
repository.GetUserString = username => new User();

We can also replace static methods with our own implemention.

public static class Util
{
    public static User GetUser(string username)
    {
        // ...
    }
}

The shim:

ShimUtil.GetUserString = username => new User();

Shims also allow us to override the behavior of base classes. Here we have a CachedUserRepository, which caches any users returned from UserRepository. If a user is found in the cache, the cached user will be returned. If a user is not found in the cache, we will use the base class to retrieve the user and add it to the cache.

public class CachedUserRepository : UserRepository
{
    private static List<User> cache = new List<User>();

    public new User GetUser(string username)
    {
        User cachedUser = cache.FirstOrDefault(x => x.Name == username);
            
        if (cachedUser != null)
            return cachedUser;

        User user = base.GetUser(username);

        if (user != null)
            cache.Add(user);

        return user;
    }
}

Using shims, we can replace the the base method base.GetUser(). By creating a shim for the base class and passing the inheriting class to the shim’s constructor, we can override the base class’s behavior.

[TestMethod]
public void Demo()
{
    using (ShimsContext.Create())
    {
        var cachedRepo = new CachedUserRepository();
        var baseClass = new ShimUserRepository(cachedRepo);

        baseClass.GetUserString = 
            username => new User { Name = "Malvin", Password = "password" };

        var user = cachedRepo.GetUser("x");

        Assert.AreEqual("Malvin", user.Name);
    }
}

The new Fakes Framework is definitely a great tool for testing legacy code, but I would be hesitant to use it for anything else. Most existing mocking frameworks have a much cleaner API. Refactoring can be difficult since the framework generates strongly typed stubs and shims for an assembly. Renaming methods or classes in the original assembly will cause your tests to fail. I would also suggest that if you’re using shims extensively in a new project, there’s probably something wrong with your design.

Just prototyping out some ideas, an API like this may be useful:

NewAppDomain.Execute(() =>
{
	// Run code in here
});

Each call to Execute would create a new application domain.

AppDomain domain = AppDomain.CreateDomain("New App Domain: " + Guid.NewGuid());

To execute our Action that we’re passing to the Execute method, we’ll need to create a new instance of Action in our new application domain. However, trying to call the CreateInstanceAndUnwrap method on the new application domain will throw an exception:

Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Action' not found.

Instead, we’ll need to create a new class that can be instantiated in the new application domain. This new class AppDomainDelegate will act as a delgate and execute the Action that we pass to it.

public static class NewAppDomain
{
    public static void Execute(Action action)
    {
        AppDomain domain = null;

        try
        {
            domain = AppDomain.CreateDomain("New App Domain: " + Guid.NewGuid());

            var domainDelegate = (AppDomainDelegate)domain.CreateInstanceAndUnwrap(
                typeof(AppDomainDelegate).Assembly.FullName,
                typeof(AppDomainDelegate).FullName);

            domainDelegate.Execute(action);
        }
        finally
        {
            if (domain != null)
                AppDomain.Unload(domain);
        }
    }

    private class AppDomainDelegate : MarshalByRefObject
    {
        public void Execute(Action action)
        {
            action();
        }
    }
}

Now we can use this class to execute code in another application domain.

NewAppDomain.Execute(() =>
{
    Console.WriteLine("Hello World");
});

Parameters

Trying to use variables declared outside the scope of the lambda will throw a serialization exception.

int i = 0;

NewAppDomain.Execute(() =>
{
	Console.WriteLine("Hello World " + i);
});

We can update the code to receive parameters across application domains by adding an overload for the Execute method:

public static class NewAppDomain
{
    public static void Execute(Action action) { ... }

    public static void Execute<T>(T parameter, Action<T> action)
    {
        AppDomain domain = null;

        try
        {
            domain = AppDomain.CreateDomain("New App Domain: " + Guid.NewGuid());

            var domainDelegate = (AppDomainDelegate)domain.CreateInstanceAndUnwrap(
                typeof(AppDomainDelegate).Assembly.FullName,
                typeof(AppDomainDelegate).FullName);

            domainDelegate.Execute(parameter, action);
        }
        finally
        {
            if (domain != null)
                AppDomain.Unload(domain);
        }
    }

    private class AppDomainDelegate : MarshalByRefObject
    {
        public void Execute(Action action) { ... }

        public void Execute<T>(T parameter, Action<T> action)
        {
            action(parameter);
        }
    }
}

Now we can pass parameters to the method. We’ll need to make sure that any parameters we pass are marked as Serializable since they will be serialized and deserialized across application domains.

int i = 0;

NewAppDomain.Execute(i, x =>
{
    Console.WriteLine("Hello World " + x);
});

Returning Results

In cases where we want the Execute method to return results, we can add two additional method overloads that use Func<T> instead of Action:

public static T Execute<T>(Func<T> action)
{
    AppDomain domain = null;

    try
    {
        domain = AppDomain.CreateDomain("New App Domain: " + Guid.NewGuid());

        var domainDelegate = (AppDomainDelegate)domain.CreateInstanceAndUnwrap(
            typeof(AppDomainDelegate).Assembly.FullName,
            typeof(AppDomainDelegate).FullName);

        return domainDelegate.Execute(action);
    }
    finally
    {
        if (domain != null)
            AppDomain.Unload(domain);
    }
}

public static TResult Execute<T, TResult>(T parameter, Func<T, TResult> action)
{
    AppDomain domain = null;

    try
    {
        domain = AppDomain.CreateDomain("New App Domain: " + Guid.NewGuid());

        var domainDelegate = (AppDomainDelegate)domain.CreateInstanceAndUnwrap(
            typeof(AppDomainDelegate).Assembly.FullName,
            typeof(AppDomainDelegate).FullName);

        return domainDelegate.Execute(parameter, action);
    }
    finally
    {
        if (domain != null)
            AppDomain.Unload(domain);
    }
}

… and the same overloads for the delegate class AppDomainDelegate:

public T Execute<T>(Func<T> action)
{
    return action();
}

public TResult Execute<T, TResult>(T parameter, Func<T, TResult> action)
{
    return action(parameter);
}

We can now get results back. We’ll need to make sure that any results we return are marked as Serializable.

Result first = NewAppDomain.Execute(() => new Result());
Result second = NewAppDomain.Execute(parameter, x => new Result());

Using The Class

The entire class can be found here. To demonstrate, we’ll create a class that uses a public static field as a counter.

public class SharedClass : MarshalByRefObject
{
    public static int Counter = 1;

    public void Print()
    {
        Console.WriteLine(AppDomain.CurrentDomain.FriendlyName + " - " + Counter);
        Counter++;
    }
}

We’ll call the Print method in another application domain using our NewAppDomain class:

NewAppDomain.Execute(() =>
{
	new SharedClass().Print();
	new SharedClass().Print();
});

NewAppDomain.Execute(() =>
{
	new SharedClass().Print();
	new SharedClass().Print();
	new SharedClass().Print();
	new SharedClass().Print();
});

The result:

New App Domain: 3ca2e6de-a5bd-40ef-b471-edb8c19024c2 - 1
New App Domain: 3ca2e6de-a5bd-40ef-b471-edb8c19024c2 - 2
New App Domain: 2037d461-79fe-48c1-abf1-2c58bb6b02cf - 1
New App Domain: 2037d461-79fe-48c1-abf1-2c58bb6b02cf - 2
New App Domain: 2037d461-79fe-48c1-abf1-2c58bb6b02cf - 3
New App Domain: 2037d461-79fe-48c1-abf1-2c58bb6b02cf - 4

If the application domain was the same, we would have seen the counter increment to 6. Notice that SharedClass inherits from MarshalByRefObject. If we instantiate a new instance of SharedClass and pass it as a parameter to our Execute method, this object is now shared across application domains via remoting. To demonstrate, we can use the Execute overload that takes a parameter:

var sharedClass = new SharedClass();

sharedClass.Print();
sharedClass.Print();

NewAppDomain.Execute(sharedClass, x => x.Print());

sharedClass.Print();

The result:

AppDomainDemo.exe - 1
AppDomainDemo.exe - 2
AppDomainDemo.exe - 3
AppDomainDemo.exe - 4

As expected, the counter did not reset. However, if we change SharedClass by removing MarshalByRefObject and marking the class as Serializable, we’ll see a different result:

AppDomainDemo.exe - 1
AppDomainDemo.exe - 2
New App Domain: b9404ee9-f4fc-4937-84ad-9d0369e36bb6 - 1
AppDomainDemo.exe - 3

public void SomeMethod(Func<Person, bool> condition)
{
	if (!condition(person))
	{
		Log.Info("Condition was not met.");
		return;
	}

	// Do something
}

If I called the method like so:

obj.SomeMethod(x => x.Name == "Malvin");

… I would like to be able to turn that lambda expression into a meaningful string.

Unfortunately, there doesn’t appear to be an easy way to turn a lambda expression into a readable string. Instead, I had to use expression trees.

public void SomeMethod(Expression<Func<Person, bool>> expression)
{
	if (!expression.Compile()(person))
	{
		Log.Info("Condition was not met: " + expression);
		return;
	}

	// Do something
}

Now if I call the method and the condition fails, I should see:

Condition was not met: x => (x.Name == "Malvin")

However, expression trees are much more expensive than lambda expressions. Running a non-scientific benchmark on my Core i7 @ 3.2 GHz yields some fairly obvious results.

void Main()
{
	Stopwatch sw = Stopwatch.StartNew();
	
	for (int i = 0; i < 100000; i++)
		UsingExpression(() => false);
	
	sw.Stop();
	
	Console.WriteLine ("Expression: " + sw.ElapsedMilliseconds);
	
	sw.Restart();
	
	for (int i = 0; i < 100000; i++)
		UsingLambda(() => false);
		
	sw.Stop();
	
	Console.WriteLine ("Lambda: " + sw.ElapsedMilliseconds);
}

public void UsingExpression(Expression<Func<bool>> expression)
{
	if (expression.Compile()())
		Console.WriteLine ("hello world");
}

public void UsingLambda(Func<bool> condition)
{
	if (condition())
		Console.WriteLine ("hello world");
}

Output:

Expression: 4154
Lambda: 0

This may be a problem for high volume systems, but I don’t think the extra overhead will be an issue for most cases.

Explicit cast:

string str = (string)someObj;

ToString() method:

string str = someObj.ToString();

Convert.ToString() method:

string str = Convert.ToString(someObj);

as operator:

string str = someObj as string;

Explicit casts should be used at times when you are sure that someObj is a string. It also doubles as an assertion since an InvalidCastException will be thrown at runtime if the cast fails. The result will be null if attempting to cast a null object.

The ToString() method returns the string representation of an object. If someObj is null, a NullReferenceException will be thrown.

The Convert.ToString() method behaves differently depending on the type of object passed to the method. When an object is passed to the method, it calls the ToString() method on the object:

public static string ToString(Object value) 
{
	return ToString(value, null);
} 

public static string ToString(Object value, IFormatProvider provider) 
{ 
	IConvertible ic = value as IConvertible; 
	
	if (ic != null)
		return ic.ToString(provider); 
		
	IFormattable formattable = value as IFormattable;
	
	if (formattable != null)
		return formattable.ToString(null, provider);
		
	return value == null ? String.Empty : value.ToString(); 
}

When a string is passed to the Convert.ToString(), it simply passes through:

public static String ToString(String value) 
{
	Contract.Ensures(Contract.Result<string>() == value);
	return value; 
}

This is important to remember because if a null object is passed to the Convert.ToString() method, an empty string is returned. However, if a null string is passed to the method, a null is returned.

The as operator provides a way to cast an object without throwing an exception if the cast fails. If a cast fails, the result will be null.