Partager via

Visual Basic .NET Design-Time Breaking Changes

  • Article
 
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.