Why not? From VB.NET, can call the original .NET Framework, e.g., 4.0, 4.5, whatever, including ASP.NET and ADO.NET.
Side issue: Just what the .NET Core is and/or its pros/cons I don't know. Microsoft's documentation seems to assume I already know what the Core is and why I'd want it. Not the first time Microsoft didn't do well explaining their work.
Microsoft: I don't have even as much as a weak little hollow hint of a tiny clue what the heck the .NET Core is or why I would or would not want it; the times I tried to find out were all self-inflicted tooth drilling; I likely don't need the Core or have to care about it so gave up trying to find out.
Next, on Windows, AFAIK, the main alternative to VB.NET would be just C#. My understanding is that VB.NET and C# differ mostly only in their particular flavors of syntactic sugar and that there is a translator from one to the other, maybe from VB.NET to C#.
The flavor of C# was borrowed from C, and I don't like it. Back to K&R, the C syntax was deliberately absurdly sparse and idiosyncratic. I wrote some C code; I mowed grass in 103 F; I shoveled snow in 0 F; I didn't like any of those three.
The VB.NET syntax is closer to traditional for Pascal, PL/I, Fortran, and Algol. Compared with C#, IMHO VB.NET is easier to read, write, teach, and learn and less prone to errors from obscure syntax.
With VB.NET I get (A) objects, (B) strings, (C) memory management ("Look, Ma, no memory leaks!"), (D) good enough exceptional condition handling, (E) platform invoke for calling, say, C, (F) fast compiling with good error messages and so far no bugs encountered, (G) reasonably good documentation, (H) ability to have subroutines and functions and some scope of names functionality, (I) the usual Do While and If-Then-Else, (J) the math functions and some good time and date handling functions,(K) easy comment syntax, .... Looks fine to me.
I'd like more on scope of names, e.g., as in PL/I. Maybe a pre-processor, e.g., again as in PL/I, would be nice. At times longer precision arithmetic would be nice; I don't know what the latest x86 has in hardware. And I can think of some things new to programming languages that would be nice.
But I can't complain: VB.NET has let me write my 24,000 statements in 100,000 lines of typing (just from my favorite editor KEdit and a lot of macros but no use of an IDE). So, with the 100,000 lines for 24,000 statements, there is a lot of internal documentation.
I had no trouble debugging the code. I wrote no prototype code, and my code doesn't need refactoring. The code looks fine for quite significant production.
For ASP.NET and IIS, maybe I could gripe: First, I didn't like their approaches to Web user session state. So, I wrote my own Web Session State Server, just TCP/IP socket communications with de/serialization, and two instances of their main collection class -- darned fast and easy enough to scale just via sharding, even without Web user session affinity. For the input queue, I just used the TCP/IP FIFO; the queue depth permitted should be deep enough.
For a Web site log server, again I don't like what Microsoft has so, as soon as I rebuild the main boot partition on my development computer from a disaster, I'll take the Web Session State Store, rip out the use of the collection class, put in a file write statement, and, presto, bingo, get a Web site log server.
In total the work had a lot of mud wrestling and fighting unexpected problems.
But the work that was uniquely mine and at all predictable was all fast, fun, and easy.
Side issue: Just what the .NET Core is and/or its pros/cons I don't know. Microsoft's documentation seems to assume I already know what the Core is and why I'd want it. Not the first time Microsoft didn't do well explaining their work.
Microsoft: I don't have even as much as a weak little hollow hint of a tiny clue what the heck the .NET Core is or why I would or would not want it; the times I tried to find out were all self-inflicted tooth drilling; I likely don't need the Core or have to care about it so gave up trying to find out.
Next, on Windows, AFAIK, the main alternative to VB.NET would be just C#. My understanding is that VB.NET and C# differ mostly only in their particular flavors of syntactic sugar and that there is a translator from one to the other, maybe from VB.NET to C#.
The flavor of C# was borrowed from C, and I don't like it. Back to K&R, the C syntax was deliberately absurdly sparse and idiosyncratic. I wrote some C code; I mowed grass in 103 F; I shoveled snow in 0 F; I didn't like any of those three.
The VB.NET syntax is closer to traditional for Pascal, PL/I, Fortran, and Algol. Compared with C#, IMHO VB.NET is easier to read, write, teach, and learn and less prone to errors from obscure syntax.
With VB.NET I get (A) objects, (B) strings, (C) memory management ("Look, Ma, no memory leaks!"), (D) good enough exceptional condition handling, (E) platform invoke for calling, say, C, (F) fast compiling with good error messages and so far no bugs encountered, (G) reasonably good documentation, (H) ability to have subroutines and functions and some scope of names functionality, (I) the usual Do While and If-Then-Else, (J) the math functions and some good time and date handling functions,(K) easy comment syntax, .... Looks fine to me.
I'd like more on scope of names, e.g., as in PL/I. Maybe a pre-processor, e.g., again as in PL/I, would be nice. At times longer precision arithmetic would be nice; I don't know what the latest x86 has in hardware. And I can think of some things new to programming languages that would be nice.
But I can't complain: VB.NET has let me write my 24,000 statements in 100,000 lines of typing (just from my favorite editor KEdit and a lot of macros but no use of an IDE). So, with the 100,000 lines for 24,000 statements, there is a lot of internal documentation.
I had no trouble debugging the code. I wrote no prototype code, and my code doesn't need refactoring. The code looks fine for quite significant production.
For ASP.NET and IIS, maybe I could gripe: First, I didn't like their approaches to Web user session state. So, I wrote my own Web Session State Server, just TCP/IP socket communications with de/serialization, and two instances of their main collection class -- darned fast and easy enough to scale just via sharding, even without Web user session affinity. For the input queue, I just used the TCP/IP FIFO; the queue depth permitted should be deep enough.
For a Web site log server, again I don't like what Microsoft has so, as soon as I rebuild the main boot partition on my development computer from a disaster, I'll take the Web Session State Store, rip out the use of the collection class, put in a file write statement, and, presto, bingo, get a Web site log server.
In total the work had a lot of mud wrestling and fighting unexpected problems.
But the work that was uniquely mine and at all predictable was all fast, fun, and easy.