Upgrading to Whidbey Beta 2

Here is an ongoing list of issues encountered during a trial upgrade of our VB.NET app to Visual Studio.NET 2005 Beta 2. These are still very early days, so I expect more to come out of the woodwork, but at least our solution loads into this version—Beta 1 upgraded the projects and then complained that they were corrupt!

Use of Object as a switch statement selector

The programmer forgot to typecast an Object instance (retrieved from a database) before using it in a switch statement. This works in 2003 but not in 2005. You get the following error: "Error 133 Option Strict On disallows operands of type Object for operator '='. Use the 'Is' operator to test for object identity."

As it says, Option Strict must be on for this to show up (annoyingly the installation default is still Off). Example:

Private Sub Test()

Dim colour As Object = Color.Red

Select Case colour 'Needs to be CType'd otherwise...

Case Color.Red 'Error here,

Case Color.White 'here,

Case Color.Blue 'and here.

End Select

End Sub

Inconsistent DLL References

Some of the projects in our solution referred to one particular DLL (FarPoint Spread) in the GAC while other projects referred to it in the programs folder (the same assembly version was begin referred to in all cases). At least this was the situation after the solution was upgraded. Whidbey complained about this when VS2003 never had.

Invalid Type Casts

In a couple of places in the code the developer had coded a DirectCast that was never going to work. This must have been in dead code because we never discovered it in testing (or production). VB 2005 has better compile-time type checking and picked up on these errors.

Decrypting a 0-Length Buffer

CryptoStream.Close threw if it was asked to decrypt a 0-length stream. This just worked in VS2003.

SqlCommand.Parameters.Add(String, Object) Obsoleted

This overload has been obsoleted because it can lead to ambiguous calls. AddWithValue should be used instead. I found more info here.

ArrayList.IndexOf Behaviour Change

In VS2003, a call to ArrayList.IndexOf(x) would call x.Equals(item) for each item in the list. In Whidbey, it calls item.Equals(x) for each item instead. This broke our app because we hadn't observed the Object.Equals override requirement that x.Equals(y) returns the same value as y.Equals(x). I have raised this as a compatibility bug at the MSDN Product Feedback Centre. (Update: the new behaviour will remain.)

Accessing Controls from the Wrong Thread

I knew that you should only access a control from the thread that created it, but we've been getting away with setting label text directly from a worker thread (until now).

P.S. Thanks to JFo for more info on this, i.e. you can set Control.CheckForIllegalCrossThreadCalls to False to bypass this check (if you're feeling naughty).

A Googol Warning Messages

Well, perhaps not quite that many, but there sure are a lot. I'm just beginning to sort through them.