A Tale of Two Types

Okay, the title was just too convenient to pass up, but this post is really a bit about nullable types and compatibility with .NET 1.1 code.

I was surprised to find that .NET 2.0 nullable types, when passed to code compiled by .NET 1.1, are not recognized as null, even when that library is being hosted by the 2.0 VM.

Now, I would not expect to be able to pass a nullable type into a 1.1 method expecting its non-nullable type without first casting it to that type. However, when passing it to a method expecting an object, I would expect it to be able to slide in just fine.

Not so.

int? i = GetInt("/foo/missingint");
Assert.IsTrue(i == null); // passes
Assert.IsNull(i); // fails

Changing int? i to object i didn’t work either. It may be that auto-boxed types—at least 1.1’s implementation—are incompatible with nullable types.

Adventures in DotNet

Old Delphi hands won’t have to think twice about how to insert a literal (percent sign) in a Format statement—you double it of course (%%).

DotNet newbies, go with your gut and do the same thing in String.Format calls—double your { and } characters in formatting strings if you intend them as literals.

Everything you know is wrong

You know how to access the configuration file from a DotNet app, right? You use System.Configuration.ConfigurationSettings.AppSettings, which is a static property that you index with a string.

However, if you’ve been around .NET 2.0 a little and have seen lists of feature changes in ADO.NET, you’re aware that there is now special support for connection strings. Books and websites will both tell you not to use ConfigurationSettings.AppSettings for connection strings anymore. Instead, you should use ConfigurationSettings.ConnectionStrings. This is the preferred way and possibly the only way if you’re trying to do fancy things like encrypt your connection strings or make your application database independent using provider factories.

Attempting this in Whidbey Beta 2 may cause you to doubt your intelligence and waste entirely too much time Googling websites that all have the same dated information and searching in local assemblies.

Beta 2, it turns out, has moved the functionality to ConfigurationManager.ConnectionStrings. Use something like ConfigurationManager.ConnectionStrings[“myalias”].ConnectionString.

And that’s life on the bleeding edge.