They improved it later with some VB6 compatibility packs, but yes, that should have been there from the beginning.

Or as I mention on another thread, .NET should have been what was later WinRT, by improving COM tooling and that was it, but now we are 20 years too late to fix that.

You're right, WinRT should have been much sooner.

However, there wouldn't have been much hope for a cross-platform .NET if it were COM based... and cross-platform is one of the things keeping .NET relevant - Personally, I was (reluctantly) about to ditch .net until that.

The cross-platform story is still half hearted, as many tools are VS only, and who knows if they ever going to land on VSCode or VS4 Mac.

Also see MAUI versus Swing/Qt, one needs to go for Uno/Avalonia instead.

Can you be more specific on the 2nd paragraph for someone ignorant like myself?

You can start here for a complete picture,

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

Well, VB.NET was little more than a variety of C# without curly brackets and with more keywords. AIUI, it was quite possible to transpile from one to the other at will. Though I think that some convenience features went the VB.NET to C# direction, so it wasn't totally without consequence.

Both vb.net and C# compile to the same bytecode. So fundamentally, if you code for a hobby or are a lone coder, it's down to what you prefer (I prefer vb.net over C#), however organisations made it clear early on that C# was much preferred so that's what prevailed.

If I'm quickly knocking up a small GUI utility then the drag-drop building nature of a vb.net forms app is a real time saver - but in contrast you have more flexibility if you build controls via code like C# does.... horses for courses really.

Bizarrely, I've recently started exploring using C# as a CGI back-end via .NET core on Linux... for the simple reason that I can. Apparently it can be quite performant.

Microsoft does not develop VB.NET further.

They do, but not adding features to please us language geeks, rather what makes sense to interop with .NET libraries, CLS compliant.

Roslyn for VB.NET still gets more love than F# across .NET workloads.

Now it is true that they could rename CLR into C# Language Runtime, given the extent of effort that C# gets, versus VB.NET, F# and C++/CLI.

Isn't the Roslyn compiler open source? It might be possible to maintain a fork and bring the language to parity with upcoming C#/.NET features.

They share the same IL so you can go VB.NET <=> Byte Code <=> C#, or any .Net language. C# diverged in terms of features though.

Yeah IIRC there was a tool that would produce an AST that would generate C#, VB.Net and J#. It was used for writing examples.