As of today I’ve been published in an e-Book offered for free by Red Gate! It is called 50 Ways to Avoid, Find and Fix ASP.NET Performance Issues and contains many useful performance tips which have been contributed by various members of the .NET community. Many tips are ASP.NET MVC specific which is also a plus.

My tip is #3 and has to do with debugging Microsoft symbols.

Get a free copy here – it has already taught me a few things I had never thought to consider!

Most of us have been there: you’ve written a fantastic application that performs perfectly in your Development and/or QA environments, but in Production something goes wrong. Your application spins out of control, utilizing 100% of your CPU. Maybe it simply stops responding as if it were deadlocked. Or maybe it simply crashes randomly. What now?

Logic tells you that you have a problem in the code somewhere that is only encountered in a Production-like environment… and if you could JUST get into the Production box, install Visual Studio (or at least the Remote Debugger), and debug the application, you’d be able to solve the problem. However, you can’t (because it’s Production!), and you can’t replicate the problem in any other environment. Maybe it’s because of stale Development or QA environment data compared to live Production data. Maybe it’s something else. You have no idea where to look to find and fix the problem in your application. For lack of eloquence: you’re screwed.

So, this post is about our beloved IDE instead of actual code.

I recently upgraded my home PC from Visual Studio 2010 and 11 Beta to Visual Studio 2012. The very first thing I noticed was that after about 10 minutes of programming my Intellisense quit working and never came back. I thought to myself “what the hell Visual Studio? 2010 didn’t have these problems?!” and then, after a swig of beer, proceeded to exercise my Google-Fu to solve this issue.

A friend of mine commented on my last post asking about how much faster the static string.Equals method is than the instance string.Equals method. To satiate both of our curiosities, I have created this benchmarking application:

static void Main(string[] args)
{
    var stopwatch = new Stopwatch();
string a = "hello";
string b = "hi";

stopwatch.Start();
for (int i = 0; i < 10000000; i++)
{
    a.Equals(b);
}
stopwatch.Stop();

Console.WriteLine("Instance string.Equals over 10,000,000 iterations: " 
    + stopwatch.ElapsedMilliseconds + " ms");

stopwatch.Reset();

stopwatch.Start();
for (int i = 0; i < 10000000; i++)
{
    string.Equals(a, b);
}
stopwatch.Stop();

Console.WriteLine("Static string.Equals over 10,000,000 iterations: "
    + stopwatch.ElapsedMilliseconds + " ms");

Console.ReadKey();

}

The results of 5 runs, where “I” is the instance method and “S” is the static method, and the times are in milliseconds:

As you may or may not know, static methods are usually faster than instance methods. This alone should be a good enough reason to use the static string.Equals method in .NET, but if that doesn’t do it for you, allow me to present a simple example.

string a = "hello";
string b = "hi";
bool result = a.Equals(b);

What is the expected result of these lines? A boolean value of false, of course. And it’d be true if the strings were identical. It’s also false if b is null. But what if a is null?

Well, it’s been nearly 2 months since my last post… I’m learning that if you want a blog to be successful, you have to carve time out of your busy life and make it happen. So, with renewed focus, I re-enter the fray.

The Joel Test is a curious and honest thing. It has been around since the year 2000 and was invented by a guy named Joel Spolsky, as the name might imply. In short, it’s a very brief questionnaire that evaluates the quality of your software development team, and implicitly their happiness as well.

This isn’t a very technical post, but I was published by Microsoft recently via their MSDN UK Blog! The article is on creating and maintaining a successful User Group.

Click here to read the article!

Two of my colleagues (one from work and one from a user group) kindly pointed out to me that in my last post I omitted Continuation Tasks as a means of Error Handling for the TPL. As such, I will expand upon my last post with an example of handling errors via a Continuation Task.

Continuing where we left off last, the following code will utilize a Task Continuation to handle errors within Tasks.

As of .NET 4.0, the TPL or Task Parallel Library is king when it comes to parallelization. It allows for smooth, easy multi-threading for any application. There is a slight learning curve, however, and a major part of this is understanding how Exceptions bubble-up while using the TPL.

Let’s partake in a simple example. This code will create and run a task that throws an Exception, and then attempt to catch it:

The .NET compiler is a terrific thing… After all, it turns your C# into an executable program!

One nice feature of the .NET compiler, which is becoming better each release, is inferred typing. I’d like to lay out a few short examples that might help you develop your programming standards and practices.

Inferring a type when creating an array.

// Create and initialize an array
var myArray = new int[] { 1, 2, 3 };

Becomes: