Visual Basic Breaking Changes in Visual Studio 2012
The following table lists changes that might prevent an application that was created in Visual Basic 2010 from compiling in Visual Basic in Visual Studio 2012 and changes might change the run-time behavior of an application.
|
Category |
Issue |
Description |
|---|---|---|
|
Type inference |
In a Return statement where the operand is an array literal, the runtime array type is determined from the function signature instead of being inferred from the array literal. |
This change lets you return an array literal in places where you couldn’t before, as the following example shows: Function GetArrayLiteral(ByVal number As Integer) As Integer() If number < 0 Then ' In Visual Studio 2010, this array literal is ' is inferred to be an array of objects, which ' cannot be converted to an array of integers. ' In the current version, this array literal is ' inferred to be an array of integers, which is ' the return type of the function. Return {} Else Return {number} End If End Function This change might result in the runtime type of an array literal being wider than what it was in Visual Basic 2010, as the following example shows: Private Sub ArrayLiterals() Dim theArray = GetArray() Console.WriteLine(theArray.GetType().FullName) End Sub Private Function GetArray() As Object() Return {"chromatic", "infinitesimal"} End Function ' Output in the current version: ' System.Object[] ' Output in Visual Studio 2010: ' System.String[] |
|
Lambda expressions |
In a For Each expression, you can now use the control variable in a lambda expression. |
The use of a For Each iteration variable in a lambda expression no longer causes a compile-time warning and no longer has unexpected results, as the following example illustrates: Dim methods As New List(Of Action) For Each word In {"hello", "world"} methods.Add(Sub() Console.Write(word & " ")) Next methods(0)() methods(1)() ' Output in the current version: ' hello world ' Output in Visual Studio 2010: ' world world |
|
LINQ expressions |
In a For Each expression, you can now use the control variable in a LINQ expression. |
The use of a For Each iteration variable in a LINQ expression no longer causes a compile-time warning and no longer has unexpected results, as the following example illustrates: Dim lines As New List(Of IEnumerable(Of String)) For Each number In {1, 2, 3} Dim line = From letter In {"a", "b", "c"} Select number.ToString & letter lines.Add(line) Next For Each line In lines For Each entry In line Console.Write(entry & " ") Next Console.WriteLine() Next ' Output in the current version: ' 1a 1b 1c ' 2a 2b 2c ' 3a 3b 3c ' Output in Visual Studio 2010: ' 3a 3b 3c ' 3a 3b 3c ' 3a 3b 3c |
|
Overload resolution |
If two overloads with generic type parameters match a caller equally well but one overload is more specific, the more specific overload is used. |
This condition caused an overload resolution compile-time error in Visual Studio 2010. In the following example, the Process(theList) line causes a compile-time error in Visual Studio 2010. In the current version, the line matches the more specific overload of the Process method.
Private Sub Test()
Dim theList As New List(Of Integer)
Process(theList)
Dim theQueue As New Queue(Of Integer)
Process(theQueue)
End Sub
Private Sub Process(Of T)(ByVal theList As List(Of T))
Debug.WriteLine("first overload")
End Sub
Private Sub Process(Of T)(ByVal x As T)
Debug.WriteLine("second overload")
End Sub
' Output:
' first overload
' second overload
|
