It had to be done – here’s how we did it.
ASP.NET WebForms is an older technology now, designed to be written in a similar way to WinForms.
If you’ve inherited an old ASP Classic website (I did at a previous job), then if you were to rewrite it, you would probably go MVC + Razor or the up and coming Blazor (which I’m excited about). But in my case this website was the lifeblood of the company that not only contained the ASP Classic front-end but was powered by a VB6 back-end. Yuck. IIS was even forced to run in 32bit legacy mode to continue to cater for this website and we had a dedicated Windows XP machine set up just for running the Visual Basic 6.0 IDE to make changes to this thing.
At https://indexsy.com/web-design/ they help you set up your presence from scratch and some will show you how to maintain it while you can pay others to maintain it for you.
Needless to say it was extremely difficult to make changes to this thing. You had to coordinate between the VB6 and ASP Classic projects using an IDE from the 90’s. Yeah I’d played with this as a teenager in high-school but here we are over 15 years later…
In an attempt to update this, the first investigation we did was whether or not we could convert the VB6 back-end to .NET. This portion of the app was compiled into a COM DLL and then registered on the host machine.
Believe it or not we actually got this working fairly well – in the first instance it kept the old COM based ADODB SQL Server connections and SMTP, etc, just to get a proof of concept up and running.
However we quickly found not all the logic we thought was running through this DLL. There were plenty of cases where logic had made its way into the ASP Classic portion of the software and for the sake of being able to extend everything in the future, we decided to dive in and convert the entire project.
The quickest port was straight to WebForms – consolidate any include files from the start and end of various files into a Masterpage file and for those familiar with ASP Classic it was common to put what you see now as codebehind at the top or bottom of an .ASP file which made it easy to pull out into the codebehind and add any public properties to the page as required then bingo-bongo we had a very quick and dirty .NET version of our ASP Classic site. Most of the time we didn’t need to even perform the moving of code to the code behind portion of the .ASPX files but it made the code a little bit cleaner.
To tidy things up a bit we ended up moving the entire external DLL into the project with a simple drag and drop of all classes and modules, removed references to COM DLLs and then the old ADODB SQL Server usage was surprisingly mostly a bunch of find & replace tasks (with some nice regex) across the thousands of places where the software was accessing the database with very minor manual touch-ups throughout.
Unfortunately to this day there is still a singleton database methodology running through the website but we have been slowly replacing this with proper connection pooling on a method by method basis and I believe we’re only down to a couple of hundred cases in one massive class file.
The project is now running on the latest .NET Framework 4.7.2 (supported in Azure as of writing) and in the couple of years since we made the conversion to WinForms – despite it being older – the website has become several orders of magnitude more maintainable and we are doing things we never would have thought possible within this project.