Supporting a Classic ASP Application
So can I get up to speed learning a dead language

This a follow on article from Learn any lanaguage
Disclaimer: This is not my first rodeo, back in 2003 when I was learning web development, Sheffield Hallam University had a Staff Intranet site that was based in Classic ASP, and I had developed some dynamic booking systems.
Classic ASP at the time shared more than a few characteristics with PHP4. But unlike PHP which has grown and developed; and I have grown and developed too, this time round I was keen to see how many modern day programming paradigms could be revered engineered to this project. See the associated article Teaching and Old Dog New Tricks
Further disclaimer: Whilst working for Twinkl, an organisation that developed on Windows, and shipped their application to Linux servers?!?!? I learnt more than a thing or two about supporting developers on this platform. Including using PowerShell Scripts to provision a new starter's box, installing all things related to LAMP stack programmatically, whilst I worked from the comfort of a lovely Mac mini.
How I run the code
Mac and Windows have never been comfortable bed fellows, my colleagues at Twinkl would delight in the fact the git-bash terminal (installed alongside git for Windows) was the closest thing you could have to working with linux (remember that old marketing advert; like a Golf, but not a Golf). Subsequently the Windows Subsystem for Linux (WSL) gives even greater close co-operation.
But it's not like you can run Classic ASP on a LAMP/ LEMP server, further more you cannot run Information Internet Services (IIS) on a mac natively. You are therefore looking for some sort of virtualisation, or hold your nose and buy a Windows laptop.
At the time there was no docker support for Windows, due to licensing problems. So I had to roll back to Vagrant and VirtualBox, something we had used for many years whilst working for Timble. Thankfully Stefan Scherer had already released a series of Window boxes; relating to his work making Docker and Window work together.
From there it was snap to come up with a number of PowerShell scripts that could provision the box for IIS, enabling SSH, set up Server Message Block (SMB) shares, generate TLS certificates, install databases, and configure IIS for Classic ASP.
All you had to do each morning is run the familiar `vagrant up`.
How I edit the code
For many years I was a big fan boy of PHPStorm, and to be far this editor does make a PHP developer's life a dream. But many of my colleagues at Twinkl used VSCode and gradually I was introduced into this way of working.
VSCode seemed more lightweight and extensible than PHPStorm, which at the end of the day only supports PHP; where as for this project I needed support for ASP as well. Luckily there was an extension for that, Classic ASP support; just what what the doctor ordered.
Dry and un-inspiring text files came to life, colours were added to variables, functions, methods, classes, which lifted them off the page. Intellisense came as standard so I could instantly tell the difference between `Response.Write` and `Response.End`. One of the first tasks therefore, was to document the code base in a similar fashion. And in this vein, the dying patient was shocked back into life.
Editing files on the guest machine would have been a nightmare, because of the small screen resolution and terrible lag times; this is where the SMB share comes into play. The guest machine is for the heaving lifting, serving up sites, hosting the database, but editing code is on my host machine and running database migrations. It provides the best of both worlds, with no limitations.
How I debug the code
Thankfully, and I was very surprised by this, IIS debugging with Visual Studio is actually a dream. And again when you are used to debugging with one language, such as setting breakpoints, conditionals, stepping through line by line; the experience is very similar.
The only bug bear is that I need to run Visual Studio on the guest machine to intercept the w3wp.exe calls. Which can lead to a laggy experience.
All you need to do is `Enable Server-side Debugging` under the Site > ASP options. Then when an error is reached in the code a prompt on the guest machine pops up:
```An unhandled exception occurred... The Just-in-Time debugger was launched```
Which kick starts Visual Studio into action. A similar response can be caused by putting a breakpoint in the code... which is literally the word `STOP`.