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

I would start looking here: https://github.com/aspcompiler/aspclassiccompiler

Thank-you, that looks like the most feasible approach for VBScript: given existing code, run it through something that would convert it to .NET.

That reminds me: it actually happened. An existing VBScript parser was used with a custom C# transpiler to generate the port to .NET, in order to realize performance and maintenance benefits.

No. But in theory you could implement a wrapper, sure. But do yourself a favor, and just rewrite your application with a modern framework.

I agree, many benefits would be realized in a modern framework.

With so much functionality stored in stored procs, VBScript was essentially just looping records and writing things out to tables. But there was lots of business logic there too.

It felt like I had a purpose liberating "old database" logic into application code--the sky castles of Brooks, as it were--where it could be changed "more easily."

Given the app was ported to C#, I suppose the stored procs would be the last to go.

Recently, I learned Cloudflare had started with lots of the domain living in the db. So it is not an unfamiliar technique, but a pleasant surprise to hear of it (for me).

The business logic you may be able to convert to VB.net. It’s a bit weird but not worse than C#.

At least one product was developed in VB.NET. We tried to keep the current conventions when maintaining or extending it. It was mostly a wrapper around stored procs, so just a lot of Response.Writes.

For some reason, to me VBScript feels like I can whip up something really quickly, and VB.NET is "all the power of the CLR, with a bit of sugar to help transition to .NET."

VB.NET does feel a bit weird. Maybe some compromises to transition folks to .NET, and from there to C#.