Why Is Visual Basic .NET Not 100% Compatible?

Why Is Visual Basic .NET Not 100% Compatible?

There were two options to consider when designing Visual Basic .NET-retrofit the existing code base to run on top of the .NET Framework, or build from the ground up, taking full advantage of the platform. To deliver the features most requested by customers (for example, inheritance, threading), to provide full and uninhibited access to the platform, and to ensure that Visual Basic moves forward into the next generation of Web applications, the right decision was to build from the ground up on the new platform.

For example, many of the new features found in Windows Forms could have been added to the existing code base as new controls or more properties. However, this would have been at the cost of all the other great features inherent to Windows Forms, such as security and visual inheritance.

One of our major goals was to ensure Visual Basic code could fully interoperate with code written in other languages, such as Microsoft Visual C#™ or Microsoft Visual C++®, and enable the Visual Basic developer to harness the power of the .NET Framework simply, without resorting to the programming workarounds traditionally required to make Windows APIs work. Visual Basic now has the same variable types, arrays, user-defined types, classes, and interfaces as Visual C++ and any other language that targets the Common Language Runtime; however, we had to remove some features, such as fixed-length strings and non-zero based arrays from the language.

Visual Basic is now a true object-oriented language; some unintuitive and inconsistent features like GoSub/Return and DefInt have been removed from the language.

The result is a re-energized Visual Basic, which will continue to be the most productive tool for creating Windows-based applications, and is now positioned to be the best tool for creating the next generation Web sites.