9. Avoid Workarounds

For most developer, the worst compatibility problem is the workaround. Yes, it makes your code work today, but what about tomorrow? Even a great workaround will cause some kind of compatibility problem, because you can be sure that Microsoft will change things just enough that the workaround won't work with the next version of the .NET Framework.

Even if you document all of these assassins of compatibility, chances are that you'll miss one of them when you modify the application to work with the next version of the .NET Framework. In many cases, the resulting bug will prove elusive, and you might never get it out of your application.

Now, before you get too upset, not all workarounds are evil. The workaround to avoid is one that relies on an incorrect behavior, such as when a method call is supposed to perform one task, but actually ends up doing something else. As previously mentioned, you also should avoid unsupported methods as a workaround. Anything that's undocumented is probably going to cause compatibility problems at some point, so don't consider adding them to your code.

It's also important to avoid using poor coding techniques as a means for creating a workaround. For example, hard-coding a value when you're supposed to derive it in some way is probably a bad choice. Always rely on best practices when creating an application to avoid the problems that workarounds can create. Unfortunate as it might seem, sometimes you have to put an application feature on the back burner until Microsoft fixes the problem that you feel requires a workaround. It's better to create great code that you know works, than to provide an application feature of dubious quality and potential problems later.

10. Employ Defensive Coding Techniques

Defensive coding seems to be a bad subject to bring up to developers. It means adding all that extra code that you know you're supposed to add, but don't because it slows the application down or could make a project late.

The problem is that defensive coding techniques also make your application more reliable and secure, while providing a hedge against compatibility problems. The simple act of adding a try...catch statement to your code won't cause that big of a performance hit, and only a few additional moments of coding time; yet, it can make the difference between an application that freezes constantly and one that can recover gracefully from compatibility problems.

Compatibility problems aren't always your fault. For example, the 1.0 version of the .NET Framework had a problem with the maxOccurs attribute of XML schemas. Using the DataSet.ReadXmlSchema() method call can produce a different result when working with the 1.1 or 2.0 version. You don't have any control over this problem; it's not in your code. However, by coding defensively, you can catch the error and handle it. The application can continue to operate as before; all you really need to add is a check to ensure that there really isn't a problem with the data.

Of course, you might not know about every compatibility problem between versions of the .NET Framework. The try...catch statement and other defensive coding strategies help you overcome exceptional conditions. Your code handles the condition, even though you didn't realize that such a condition exists when you created the application. In fact, using defensive coding effectively means that your application will likely continue to run even if someone tries to use it with a version of the .NET Framework that doesn't exist when you write the application.

Bottom Line

Compatibility issues need not spell major headaches as you develop applications. By ensuring that you spell out your application requirements, check for the correct versions of DLLs programmatically, and coding defensively, you can eliminate a large percentage of the compatibility problems that tend to cause trouble for developers today.