Analysis · 06
VB.NET and the Great Split
In February 2002, Microsoft shipped a language called Visual Basic that could not run Visual Basic programs. The community never quite forgave it; the language never quite recovered. Both halves of that sentence deserve examination.
01What actually changed
Visual Basic .NET shipped with the first version of the .NET Framework and Visual Studio .NET. From a distance it looked familiar: Dim, Sub, MsgBox's successor MessageBox.Show, the same rounded keywords. Up close it was a different machine. The language gained real object orientation: inheritance, constructors, interfaces, structured exception handling with Try…Catch…Finally after a decade of On Error GoTo. It lost, in exchange, most of its shortcuts: default properties without Set were gone, Variant became Object, array bounds and Integer widths changed semantics, and forms were no longer magical global objects but ordinary instantiated classes.
Underneath, the philosophical break was larger than the syntactic one. Classic VB, whose story is told in our history and the VB6 deep dive, compiled to a private runtime with its own rules. VB.NET compiled to the Common Language Runtime, the same intermediate language, garbage collector and class library as C#. One compiler team, in effect, had decided that the language's future mattered more than its past.
02The fracture
The migration tooling (an Upgrade Wizard in Visual Studio) converted projects the way machine translation converts poetry: recognisably, unusably. Real porting meant re-architecting forms, rewriting COM interop, and retraining teams. Many organisations made the jump across the 2000s, often alongside the move from ASP to ASP.NET described in the VBScript retrospective. A large remainder simply declined, and their refusal hardened into the defining community conflict of the era: a public petition asking Microsoft to continue classic VB gathered thousands of signatures from professional developers, and Microsoft's polite refusal (develop on VB.NET), run your old EXEs on the "It Just Works" runtime: fixed the community's geography for the next two decades: one half on the modern platform, one half on the classic one, both convinced they were the reasonable ones. The depot's coverage of the latter territory continues in Migrating VB6 Applications Today.
VB.NET was not a bad language. It was a good language wearing the name of a different one (an inheritance dispute conducted in keywords).
03The quiet maturation (2002–2020)
Left to its own merits, VB.NET grew into something respectable. The 2005 release added generics and the genuinely thoughtful My namespace, which wrapped the sprawling .NET class library in approachable shortcuts, a small, good act of respect toward the language's beginners-first heritage. The 2008 release delivered LINQ and, uniquely among .NET languages, XML literals. Later versions contributed async/await, string interpolation and tuples. For a stretch in the late 2000s, VB.NET was arguably the most productive way to build Windows Forms line-of-business applications, and a substantial professional population, the modern descendants of the VB6 consultants, built exactly that.
04Steady state (2020–2026)
The clarifying moment arrived in March 2020, when Microsoft's developer division published a plainly worded statement on the future of the language: Visual Basic would be supported indefinitely, but the company's language innovation would concentrate on C#; VB's role was stability, maintenance and the classic application types (Windows Forms), class libraries, ASP.NET. The depot reads that document as an honest epitaph for the ambition era and a promise for the maintenance era: no one's VB.NET application is going anywhere, but no one should start a green-field flagship in it either. The version and policy milestones are pinned in the timeline, and the still-vigorous surrounding community is mapped in Where Classic VB Lives On.
05The depot's verdict
Two things are true at once, and the split is still fresh enough that partisans concede only one of them. Technically, VB.NET was the right call: the CLR was a better foundation than the private VB6 runtime could ever become, and the language that resulted is clean, safe and productive. Sociologically, the transition broke something rare, the largest beginner-to-professional pipeline in software history, and nothing has fully replaced it. When people say "they don't make programming for everyone like they used to", VB6 is the "they" they mean, and the name on VB.NET's box is a large part of why it hurt.