Out with the old

My last column was about the least painful way to break up with your ISP, which set me thinking of other changes you might need to make in the near future: some are of your own making, but as we shall see, some are forced on you. Anyone who develops with Visual Basic 6 might have been worried by an MSDN survey, www.pcpro.co.uk/links/176webapp, published in January to UK VB6 developers (also via the MSDN “Flash” newsletter). It wasn’t the results as such, but the fact that Microsoft needed to ask the questions that worried me – it looked like the writing was on the wall for ending support for Visual Basic 6.

The survey revealed a lot of VB6 code in current apps – 86% of respondents said they currently maintain such code – and hardly surprisingly more than 40% intend to stick with VB6 because “if it ain’t broke, don’t fix it”. That’s a reasonable enough principle, until the OS vendor brings out an “improved” release that really does break it – something like Vista or perhaps Windows 7. Whatever the cause, chances are that you’ll be forced to rewrite the application some time soon.

For example, although ASP and Visual Studio 2008 are both fully supported on Microsoft’s server software, problems arise over development environments. Ask Visual Studio to run your web application, and it builds your project and runs it in an internal web server that supports advanced debugging capabilities. However, this internal web server, for reasons best known to Microsoft, can’t render ASP pages. There are some hoops you can jump through to make things work, by debugging on a remote IIS server, but this involves installing and running Microsoft Visual Studio Remote Debugging Monitor (msvsmon.exe) on said server. Before you try this, bear in mind that remote debugging only works with the far more expensive Pro and Team versions of Visual Studio, and for a lot of developers that closes off this route. So although you can still work with both Microsoft web technologies inside Visual Studio 2008, this lack of single stepping and debugging for ASP pages provides a compelling reason to convert all your ASP pages to ASP.NET. But for large sites this is impractical if all you need is to add some tiny new function. Invoicing your client for a rewrite of the whole site that looks exactly the same, just to make your job a bit easier, is likely to go down poorly in the present economic climate.

So why not just write a sub-site in ASP.NET and leave the rest in ASP? That might be a solution, but bear in mind that session state differs between ASP and ASP.NET, so you’ll need to sort out a way for the two apps to talk to each other if they save state. And if you have authentication on the site, think about how it will work between ASP and ASP.NET, because otherwise visitors will end up having to log in twice. There are lots of good reasons for developing websites in ASP.NET rather than ASP, but having the choice forced on you by its vendor grates enormously. Microsoft seems to think that there’s no need to fully support its own older languages in its current development tools, yet boasts of Visual Studio’s support for many of the latest languages that have far smaller (but perhaps noisier) developer communities. Why is this? Could it be these older technologies are so riddled with security holes that the safest thing is to bury them good and deep and pretend they never existed?