I'm a big fan of strongly typed database querying as well as returning strong typed results. Due to the nature of static languages, you'll get compile time checking of all our tables and columns. You can easily rename columns as you can be sure all your (internal) references are accounted for. Returning strongly typed lists of objects instead of DataReaders/DataTables / any other object based containers will also make it easier to transfer through data layers as you're always certain of what's available for you to read and what's not. But it comes at a cost. Performance. ...

Time flies fast. Back in 2006, during my time as an MSP, I made a series of presentations on securing intellectual property in .NET code, resulting in my Securing .NET Code article. Although it's about two years old, most points are still valid today, unfortunately. I recorded a screencast of this article sometime in 2007, but I never really got it published, except for a link on the Microsoft Denmark site. It was my first screencast and unfortunately I made some mistakes, the biggest one being the click sounds from the mouse. An even bigger mistake was me deleting...

I often do code profiling, usually involving a stopwatch and some boilerplate code. I decided to make a quick'n'simple class that'll help me get rid of some of that code and concentrate on the actual code being profiled. There are just four functions in the class, all overload variations. In a nutshell, they'll allow you to profile a single action with & without warmup, multiple iterations and multiple iterations run i parallel. The code is more or less self explanable so I'll just throw it out there: using System; using System.Collections.Generic; using System.Diagnostics; using System.Threading; namespace CodeProfiler { public class CodeProfiler { /// <summary> /// Measures the...

In my earlier blog post about the dangers of using Response.TransmitFile, I gave an example of a workaround involving spawning a new thread in the ASP.NET page. While this does solve the issue at hand, it presents us with a new way to kill our application even quicker than last. Usually when an uncaught exception occurs in an ASP.NET application, we will be presented with a "friendly" error message like the one below: While there is an overhead of exceptions being thrown, they're not directly dangerous and will at worst affect scalability (ignoring the actual reason...

Before attempting to optimize code or fix any kind of load issue, you should first gather data and become aware of what bottlenecks you're experiencing. A great way to do this is through the Performance Monitor application. Recently I tried monitoring my ASP.NET applications, but all my counters had a value of 0. As I thought initially, it's a simple problem, but the solution was not easily found. In some cases it might be due to lack of permissions on the performance counter registry keys. In my case it's because I was running Server 2003 x64, but my...