Visual Basic .NET Design-Time Breaking Changes

Short Description	it is invalid for a class to inherit from a class nested within it. This could occasionaly compile in 7.0
Affected APIs	None. This is a change in the language limitations. Code that would sometimes compile will now never compile.	Severity	Low	Compat Switch Available	No
Description	Class Derived inherits from a type nested within itself. This is a non-user-scenario and is forbidden in C#. Due to the way that decompilation within the VB background compiler works; it would only occasionally compile in VB7.0 and VB7.1. In 8.0 it would generate a compiler error.
User Scenario	Source upgrade scenarios. The user has defined a set of classes in V7.0 that depend on a class inheriting from a base type nested within itself. The project is then upgraded to VB.NET version 2.0. This is forbidden within the C# compiler.
Work Around	None. There would be no way to express it Visual Basic 8.0 that would compile.

 

Short Description	VB Err number returns 0 for COM exceptions with positive HResults instead of returning the HResult itself
Affected APIs	None	Severity	Low	Compat Switch Available	No
Description	In VB6 the err number would be set to the HResult. In VB7 we assume that any positive value is a passing case and set the Err number to 0 even if an exception is thrown.
User Scenario	Upgraded applications that depend upon the Err number to handle errors will now handle error cases that would have previously been reported as successes. Applications that have used the workaround should continue to work as an exception will still be thrown and the underlying COM exception would continue to contain the correct HResult value.
Work Around	Catch the exception thrown and retreive the result from the exception properties. If On Error GoTo is being used for error handling; this would require an overhaul of the entire method's error handling as On Error GoTo is incompatible with structured error handling.

 

Short Description	VB collections had a weird implementation of IList: 0 based for read and -1 based for insertion
Affected APIs	none: Ilist implementation of VB collection is fixed	Severity	Low	Compat Switch Available	No
Description	an instance of Collection type is casted to Ilist and then used via Ilist interface. To make this work in 7.0, 7.1 you would need to specialcase access to Ilist if it holds Collection
User Scenario	Upgraded apps that use VB Collection through inconsistent implementation of Ilist (very unlikely scenario) may be broken.
Work Around	code that has special-case warkarounds to use Collections casted to Ilist, will have to remove workarounds.

 

Short Description	Microsoft.VisualBasic.Collection - Remove( Key) behaves differently than vb6
Affected APIs	none: implementation of VB collection is fixed	Severity	Low	Compat Switch Available	No
Description	Removing the current element of a collection inside foreach would cause iterator to jump 2 elements. Now this is fixed.
User Scenario	Upgraded apps that remove elements from a VB Collection inside ForEach may be broken.
Work Around	Code that has workaround for old behavior now may be broken

 

Short Description	DirectCast gives error on statically invalid casts
Affected APIs	none : compiler rejects some code that would break at run time	Severity	Low	Compat Switch Available	No
Description	some cases where code would 100% fail in run time are now compile errors.
User Scenario	some code that uses statically invalid DirectCast cases will not compile in version 2.0. The only case where this code would compile and not break in run time if this particular codepath is never used.
Work Around	once recompiling an app customer should remove/fix parts of the code with statically illegal usage of DirectCast. There is changes to the behavior of already compiled code

 

Short Description	latebound floating point compare against NaN Not Equal
Affected APIs	Source breaker only due to latebinding	Severity	Low	Compat Switch Available	No
Description	Late bound/Early bound consistency. In the latebound case VB used to yeld Equal for floating poin numbers compared to NaN. In 8.0 this will yeld NotEqual to be consistent with earlybound case
User Scenario	comparing floating point numbers. This would return Equal if one of the numbers is NaN in 7.0. Customers are likely to have workarounds for this behavior.
Work Around	low impact. It is unlikely that any code could rely on this behavior. It is also should not break workarounds that could be added in 7.0 and 7.1

 

Short Description	TypeName, SystemTypeName and VbTypeName are extended for unsigned types
Affected APIs	Source breaker only due to latebinding	Severity	Low	Compat Switch Available	No
Description	in 8.0 VB fully supports unsigned numeric types. Different (more consistent) results should be yelded by TypeName, SystemTypeName and VbTypeName .
User Scenario	code that uses unsigned types and expects then not to be fully supported.
Work Around	it is unlikely that there is code that uses old limited support for unsigned types. In case it does, customer has to fix code to handle new behavior.

 

Short Description	And, Or, Xor call corresponding Iconvertible member for result type as other latebound operators do
Affected APIs	Source breaker only due to latebinding	Severity	Low	Compat Switch Available	No
Description	In v1.1, when you perform latebound operations, the VB runtime calls through the IConvertible interface to extract the strongly-typed value that matches the result type of the expression. This was not the case for And, Or, Xor. In 8.0 the behavior of And, Or, Xor will be consistent with other operations.
User Scenario	latebound Xor, Or, Xor with resulting type not matching the type of operands may behave differently.
Work Around	Customer can add explicit conversions if he wants to convert to a different types than the runtime before doing actual And, Or, Xor operations

 

Short Description	(late bound byte - nothing) returns the same type as (nothing-byte)
Affected APIs	Source breaker only due to latebinding	Severity	Low	Compat Switch Available	No
Description	Expected System.Byte on both earlybound and latebound cases—similar code in vb6 returns byte for both cases. A second argument for fixing this (apart that it's just plain wrong:)) is that it will avoid having similar behavior for the recently introduced unsigned types.
User Scenario	subtracting nothing from latebound byte
Work Around	New behavior is much more logical, however manual conversion of the operands is possible to keep old behavior.

 

Short Description	No difference between late and early bound evaluation of bitwise operators for string and boolean
Affected APIs	Source breaker only due to latebinding	Severity	Low	Compat Switch Available	No
Description	The expression result in the latebinder is Long when it should be Boolean, just as the early-bound behavior. This bug is important to fix because it can cause subtle bugs when customers decide to make their program type-safe by turing Option Strict On.
User Scenario	late bound evaluation of bitwise operators for string and boolean
Work Around	New behavior is much more logical, however manual conversion of the operands is possible to keep old behavior.

 

Short Description	Intelligently emiting assembly references
Affected APIs	Source breaker because compile time feature	Severity	Low	Compat Switch Available	No
Description	The proposed change (only emiting to the metadata references to assemblies that are used in the code) will cause a change in behavior on the System.Reflection.Assembly class, method GetReferencedAssemblies - this method lists the assemblies that are referenced, (provides information about the assemblies, not loaded assemblies).
User Scenario	This should only affect people who do not refer any types from the referenced assemblies and use the GetReferencedAssemblies method for some purpose, such as for example listing all the types in the referenced assemblies.
Work Around	GetReferencedAssemblies still works correctly. It just gives different results because we do not reference unused assemblies. It is unlikely that any workaround is needed while there are many obvious workarounds.

 

Short Description	Deal with namespace name case mismatch across referenced DLLs
Affected APIs	Namespace usage	Severity	Medium	Compat Switch Available	No
Description	If the names of two VB namespaces differ by case only, there is a new warning BC40055 about it, and C# app that referenced them using identifier of different case won't compile anymore. Example: In C# app referencing VB library: Ns.Class1 c1 = new Ns.Class1(); Ns.Class2 c2 = new Ns.Class2(); 'won't compileIn VB app:Namespace Ns Class Class1 End Class End Namespace Namespace ns 'causes compile warning Class Class2 end Class End namespace
User Scenario	Some apps that compiled against version 1.1 may fail to compile against version 2.0.
Work Around	Change the casing in the referencing application to match that in the declaration.

 

Short Description	VB compiler needs to change its typechecking to reflect that boxing a Nullable(Of T) results in a boxed T
Affected APIs	Nullable usage	Severity	Very Low	Compat Switch Available	No
Description	Bug 531200 Creating a delegate with a function pointer to a member of a Nullable(Of T) fails verification. The following code should be a compile error.Module Module1    Delegate Function BarDel() As Integer    Sub Main()       Dim x As Nullable(Of Integer) = New Nullable(Of Integer)(10)       Dim d As BarDel = New BarDel(addressof x.GetValueOrDefault)       Console.WriteLine(d())    End Sub End Module
User Scenario	This is a fit and finish issue that we won't be able to change once shipped due to compat reasons.
Work Around	If this not fixed you will get a null reference.