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:
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.
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).
A Googol Warning Messages
Well, perhaps not quite that many, but there sure are a lot. I'm just beginning to sort through them.