Classic ASP used VBScript, not VB6. These two are closely related but not quite the same.
And the answer really depends on what you mean by "run on". .NET already supports two-way COM interop, and it does work with DLR to handle stuff like IDispatch. But the COM code in that scenario is still native (or, in case of VBScript, intepreted by its Active Scripting provider).
Implementing VBScript, or even VB6, as a language running entirely on top of .NET, is certainly possible, although it would be somewhat awkward because the object model in VB pre-.NET was specifically designed around COM. You can port the templating engine, as well. But the real hurdle is not the language - it's all the APIs. ASP itself was pretty basic, but most web apps would also need to talk to the database - so now you need ADO. And then there are all the third-party components, most of which were proprietary binary blobs compiled for 32-bit Windows.
And, well, why? There are many better languages running on top of .NET these days, starting with VB.NET.
You're right. It's mostly nostalgia value :) Although I have been a hosting customer for a while now.
ES3 is nice, and short of prayer or sacrifice one was able to import Crockford's JSON library and Ramda. Server-side Node.js without npm (for better or worse).
With Babel, the idea was to use ES6 constructs and transpile it down to something IIS could run. Or Ruby, or anything else, and VBScript becomes kind of like the "machine language" description of the program.
VBScript is less painful with aspunit [1] and plenty of comisseration/resources with drian bamaged [2], aXe, and even [3].
It was amazing how much could get done with Microsoft SQL Server, a loop, and Response.Write(). Enough to build a company and to get acquired, even. Could have been a right place/right time thing for the owner.
[1] https://github.com/rpeterclark/aspunit
[2] blogsite
[3] the person with the classic ASP book
And the answer really depends on what you mean by "run on". .NET already supports two-way COM interop, and it does work with DLR to handle stuff like IDispatch. But the COM code in that scenario is still native (or, in case of VBScript, intepreted by its Active Scripting provider).
Implementing VBScript, or even VB6, as a language running entirely on top of .NET, is certainly possible, although it would be somewhat awkward because the object model in VB pre-.NET was specifically designed around COM. You can port the templating engine, as well. But the real hurdle is not the language - it's all the APIs. ASP itself was pretty basic, but most web apps would also need to talk to the database - so now you need ADO. And then there are all the third-party components, most of which were proprietary binary blobs compiled for 32-bit Windows.
And, well, why? There are many better languages running on top of .NET these days, starting with VB.NET.