Recently I found myself having to debug a large stored procedure that calls all sorts of sub-procedures. Also, the data set was rather large and it only failed sometimes. SQL Management Studio in this scenario isn't very helpful for several reasons:

• The number of PRINT messages that it'll show is limited, so if the error is out of range... tough luck.
• Even with PRINT messages it can be hard to pin down which statement is actually in error.
• Line numbers are never accurate.
• It seems View Dendencies sometimes misses out on dependencies.
• View Dependencies doesn't show the number of times a proc is called from another proc.

SQL Profiler, which also comes with SQL Server is a much better tool when it comes to pin-pointing the erronous statement(s), after which you can modify your code to show an error message that prints the values causing the hickup. When you use SQL Profiler, be sure to select more than just the default events. Click Show All Events and select all Error events, as well as the Stored Procedure events that show Starting and Completed of SQL statements with stored procedures. Then, once the root procedure is done, do a Find through the trace for "Error", and you can see exactly which statement is causing the error.

My company regularly works on public facing websites, and as such it is imperative we test the sites we create with most common browsers. Naturally that means at least Internet Explorer, FireFox, Safari, and Opera. With the last three we just download and install om some test (virtual) machine. With IE however this is somewhat more complicated (although not impossible to run different versions of IE side by side. However, Microsoft provides a set of Virtual PC images known as the Internet Explorer Application Compatibility VPC Image. These images enable you to test different versions of IE on different versions of Windows. These images have a limited lifetime (between 1-4 months), so you'll have to download a new set on a regular basis, but other than that this is really handy. The following configurations are available:

• Windows XP SP3 with IE6
• Windows XP SP3 with IE7
• Windows XP SP3 with IE8
• Windows Vista with IE7
• Windows Vista with IE8

Unfortunately these configurations are all en-US, so if you want to test with say a Dutch version of Windows, you'll have to create your own images (which is what my company has done, even for en-US).

Today http://orchard.codeplex.com/ went live. Orchard is an open source Content Management System that the folks from Redmond are working on together with the ASP.NET community, and which I've been following with much interest. Orchard is based on ASP.NET MVC, which means I'd favor it over something like Umbraco when it is mature enough. Why? Because this should mean that it blends easier with your regular development efforts, rather than having to deal with an entirely different templating technology. Umbraco for instance uses XSLT, and even though I wrote a book a about XSLT and my company is well versed in XSLT because we do a lot of BizTalk, it is troublesome for plain ASP.NET developers.

Keep in mind that Orchard is relatively new and a lot of scenario's are still not supported. But at the pace the team is going, you'll soon see more advanced stuff being possible. You can make yourself heard about what you'd like to see through CodePlex or through one of the sessions at TechEd or PDC this month.

Lately I've been making time to read more again, and I thought I'd share my findings. My most recent read is Solid Code: Optimizing the Software Development Life Cycle by Donis Marshall and John Bruno. My feelings about this book are mixed. On the one hand, it gives a good overview of software engineering practices. On the other hand, an overview is all that it is. It doesn't really do a good job at giving any details. That said, I think it is a good read for junior/medior developers to get a sense of all the stuff they should be aware of when building software. For senior developers and architects a quick scan to see if they have a gap somewhere is enough. From there you can explore books specialized at the topic(s) you need to know more about. Some of the topics covered include, design, testing, performance, scalabiltity, and security.

As an aside, I've read several books now that cover Agile development methodologies. What strikes me everytime is that the given examples are always about product development, and this book is no different. Product development and custom software projects however are very different. In product development you can work with fixed budget and fixed time, and cut features if either budget or time doesn't allow you to create them. Custom software projects can't do this as easily. Clients are not going to give you a bag of money and a schedule and say "we'll see what makes it into the final version". The client wants to know what he/she is going to get for the money they pay. This means that in custom software projects, you need to have a much more detailed view up front of what needs to be implemented. I'm not saying this precludes Agile development practices, but there is a certainly a difference at the start of the project, because a large chunk of the design work has to be done earlier in the project lifecycle.

Every once in a while (when I use a new dev environment) I hit this error:

Saving Changes in not permitted. The changes you have made require the following tables to be dropped and re-created. You have either made changes to a table that can’t be re-created or enabled the option Prevent saving changes that require the table to be re-created

Each time I forget how to fix this, so by posting here I know I'll never forget. Check Pinal Dave's blog post on this error (hint: it's in the Option menu). Thanks Pinal!

I was working on this little app I wrote a while ago and wanted to add some features requiring (de)serialization. So, I took the original class and made it a DataContract so I could use it with the DataContractSerializer. The class then looked more or less like this:

[DataContract]
public class MyClass
{
    List<Trip> m_Items = new List<Item>();

    [DataMember]
    public IList<Item> Items
    {
        get { return m_Items; }
    }
}

Serialization went fine, but when I tried to deserialize the same object, I got a null reference exception. Of course you say, you should have added a method tied to de OnDeserializing event, because the constructor of the object doesn't work and hence the m_Items field is never initialized. The code I added to solve this looked like this:

[OnDeserializing]
protected void Init(StreamingContext context)
{
    m_Items = new List<Item>();
}

To my surprise I still got the same exception. I finally figured out that the problem was the type of Items. It is was an IList<> instead of a List<>. To avoid tying a class to a specific implementation of a list, I usually use an interface, which is good practice in most cases... however, not when you want to do deserialization :).

At BataviaLabs we were debating coding guidelines the other day and came across this one: do you use #if or the ConditionalAttribute to indicate to the compiler if a method should be compiled. Let me elaborate...

If you have a method you only want to compile in a debug scenario, you have the following options:

1) Use #if DEBUG as shown below

class Program
{
    static void Main(string[] args)
    {
#if DEBUG
        SomeMethod();
#endif
        Console.WriteLine("End");
        Console.ReadKey();
    }

#if DEBUG
    internal static void SomeMethod()
    {
        Console.WriteLine("SomeMethod");
    }
#endif
}

2) Use the ConditionalAttribute as shown below

class Program
{
    static void Main(string[] args)
    {
        SomeMethod();
        Console.WriteLine("End");
        Console.ReadKey();
    }

    [Conditional("DEBUG")]
    internal static void SomeMethod()
    {
        Console.WriteLine("SomeMethod");
    }
}

The difference between these two methods is enormous. The first sample is very explicit. Any code you don't want to compile into the production build is placed between #if DEBUG and #endif. If you try to call SomeMethod in a production build, the compiler will give you a compile error. The ConditionalAttributeon the other hand doesn't require you to remove the calls to SomeMethod. If a method is marked [Conditional], any calls made to that method are removed from the build by the compiler. A proviso here is that [Conditional] only works with methods that don't return a value (i.e. void).

I much more prefer #if DEBUG, because it is explicit. I can't run into a situation where from reading the code I'm thinking "SomeMethod is being executed", but it actually isn't because the compiler removed the call. Comments anyone?

When testing a UI, especially a web UI, it is imperative you do so at all resolutions you expect your users to use. So, how do you size the browser to 1024x768 on a 1680x1050 screen? The answer is a little tool called Sizer. It allows you to set a window to a prefixed size or you can drag the window size and it will show the actual size as a tooltip.

I keep forgetting how to force the transaction log in SQL Server to shrink, so I'm posting here primarily so I know where to find the how to :). Often the log does not shrink when you try to shrink from SQL Managent Studio. The solution, before you shrink the database do:

BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY

Thanks to Pinal Dave for this one (see his post SQL SERVER - Shrinking Truncate Log File - Log Full)

We have an ASP.NET application that we normally run under Forms Authentication using the ASP.NET Membership API. For a particular client we changed this to using Windows Authentication instead. On the production environment, we were running into the following exception:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

We checked all the connection strings the app uses... all good. Finally, we figured out what was wrong. We had removed the Membership section from web.config so it was going back to the default in machine.config. That setting uses the LocalSqlServer connection string, which we don't use. However, in the default machine.config, this points to the App_Data folder using SQL Server Express. In most environments, this wouldn't be an issue immediately, because SQL Server Express would just create the  aspnet database and use that. However, in a hardened environment SQL Server Express is either not there (our case) or has no rights to create the App_Data folder and/or place create a new database. ASP.NET doesn't know this... it just can't access the SQL Server instance it is looking for, hence the above exception.