When Written: Feb 2009
In a previous article I wrote about breaking up with your ISP and the least painful way to achieve such a move. This got me thinking about some of the other changes you might need to make in the near future. Some of these choices will be of your own making but as we shall see, some may be forced on you.
Anyone who develops with Visual Basic 6 might be getting worried at the survey recently published in MSDN (http://geekswithblogs.net/iupdateable/archive/2009/02/17/results-of-the-visual-basic-survey-part-1-language-and.aspx ). This survey was done in January to UK developers known to use VB6 and also via the MSDN ‘Flash’ newsletter. What concerned me was not the results as such, but that Microsoft needed to ask these questions at all. The fact that Microsoft felt it necessary to run such a survey looks like the writing is on the wall for the demise of support for Visual Basic 6.
The survey showed that there is still a lot of code out there in current applications that use VB6 ( 86% of the developers asked, said they currently maintain such applications) and not unsurprisingly over 40% intend to leave it as VB6, after all ” if it ain’t broke then don’t fix it “! This is not a bad view to take, that is until the operating system manufacturer comes up with an ‘improved’ version that really does ‘break’ your application, like Vista or perhaps Windows 7 / 8 ? Either way the chances are that you will be forced to move your application across at some time. Take for example, ASP and Visual studio 2008. Both these are fully supported on Microsoft servers, but the problems arise in the development environment. Here, when you ask Visual Studio to run your web application it will build your project and then run it.
To run your web application Visual Studio uses an internal web server to enable its advanced debugging capabilities. However this web server, for some reason best known to Microsoft , will not render ASP pages, quite why I have no idea. Now there are some hoops that you can jump through to get things working with debugging on a remote IIS server. This involves installing and running Microsoft Visual Studio Remote Debugging Monitor ( MSVSMON.EXE ) on the web server. Before you go off and try this, just bear in mind that remote debugging will only work with the much more expensive Pro and Team Versions of Visual Studio so for a lot of developers that excludes this route. Although you can still work with both types of Microsoft web technologies within Visual Studio 2008, the lack of single step and full debugging of ASP pages certainly means that the compulsion to convert your ASP pages to ASP .NET becomes quite strong. But for large sites this is often impractical if all you want is to add some new functionality. Try invoicing your client again for rewriting all the pages on their web site which will display just the same, just to make your job a bit easier, and wait for their reaction!
So you might think, why not just write a sub-site in ASP.NET and keep the rest in ASP? Sometimes this could be a solution but bear in mind that the session state between ASP and ASP.NET is different and so you need to sort out a way for your two applications to talk to each other if you use session state at all. If you have any authentication on your web site you have to think how this might work between ASP and ASP .NET otherwise visitors will end up being asked to login twice, not very friendly. There are lots of very good reasons for developing web sites in ASP .NET versus ASP but having to be ‘forced’ to do this work from the vendor of both technologies is singularly unhelpful. Microsoft seem to be taking the view that there is no need for full support for their older languages in their current development tools, and yet they proudly show how Visual Studio fully supports many of the latest languages which have a much smaller but perhaps noisier developer community.
Why is this? Could it be these older technologies are so riddled with security holes that the best thing to do is to ‘bury’ them good and deep and in time we can all pretend they didn’t exist? If you do decide to bite the bullet and convert your old code there are third party tools out there that help with migrating from VB6 to .NET but they cost. Microsoft do is provide some tools in Visual Studio but according to Microsoft they are not as good as the third party tools. Why not ? Who designed these languages in the first place? It seems that Microsoft are slowly forcing us to move our apps and our web sites from a language where we have learnt its weaknesses and its strengths, to an new version with as yet unknown issues for performance. Perhaps the developer community has such inertia that a little bit of persuasion is needed, this is probably true as I still have a VB3 app that is occasionally used. But we are not really talking about obsolete languages here. Or are we? Perhaps Microsoft should come clean and tell us that VB6 and ASP are dead? Long live .NET! well at least until the next version !
Developers are always being tempted by slick demonstrations of cool technologies and how they will make their coding lives so much better. Funny how these never seem to live up to their initial promises? I’m sure that at the forthcoming Mix09 we shall see more of the same. I am all for embracing new technology and am a great fan of ASP .NET, but I am finding more of my working time spent switching between development tools and sometimes virtual machines just to get my work done. Gone are the days of Dreamweaver that could handle everything, along with some great rapid development extensions that enabled you to create web sites with the minimum amount of coding and the shortest amount of time. This meant that you could concentrate on the more specialised areas of a web site rather than ‘re-coding the wheel’ with each site.
Being efficient and able to product 80% of any web site in as short period of time has always been important, and even more so as economic conditions put the pressure on companies to watch costs and innovate to stay ahead. Dreamweaver does not support ASP.NET 2 and above and once you have moved across and experienced the debugging capabilities of Visual Studio 2008 then you really don’t want to revert back to the old ways of debugging without breakpoints and using code to print out variable values direct to your web pages. Dreamweaver CS4 is still a very powerful web design tool and the code it now writes is much better and more secure than previous versions; however it is being aimed now at the large mass of PHP and MySQL developers as well as obviously integrating with Adobe’s Spry (AJAX) framework. So for the developer of Microsoft technologies there is slowly becoming only one choice and that is to use the tools from Microsoft itself. But I wonder how the development community feel about older technologies being forced out as these tools no longer support them?
As an example of such a scenario, where the question of whether or not to upgrade existing code in a web application, came up the other month. This client’s web site was written in ASP with one page written in an early form of ASP .NET AJAX. I needed to add a couple of similar pages and convert the whole site to multilingual. Now in theory doing multilingual sites in ASP .NET is a piece of the proverbial. You simply need to create a resource file for each page and each language and as this file, which is XML in structure, can be created automatically in Visual Studio in design mode simply by selecting ‘new resource file’ things should be simple. But there is a problem with this. Not everything on your page will appear in this resource file, just the text in Label controls. Also if you have any dynamically produced text, like for example the text in an error box then you have to write code to produce the correct language version for this. Also this site was to have ten languages so for every page on this web site I would need ten resource files.
I considered using resource files to handle my translated text but on consideration, the thought of maintaining a file for each language for each page sounded like an admin job from hell. If you just need one or perhaps two extra languages then it might be for you, but I needed an easy to maintain solution that would handle UTF-8 character sets so that languages like Polish would be correctly rendered. I even considered generating these resource files directly from a database. In the end I decided to go the old route of storing the various phrases in a database with a separate record for each language. Using this technique I didn’t need to convert my old ASP pages to ASP.NET to use resource files in them.
Again I am baffled at Microsoft in providing a mechanism such as resource files without the ability to easily create them on the fly from a database, instead of using a collection of files where a lot of the text could be similar between pages. ASP .NET is extremely extensible and I’m sure someone will write in to inform me that I could write a class that hooks into some obscure call in the system that will achieve what I want. Whilst it is great to have such flexibility it is often my experience that software houses can use this as an excuse to leave their product incomplete, falling back on the excuse that you could always ‘modify/write that functionally yourself’. So did my solution work? Yes like a dream, well…. except for the button control in ASP .NET. It seems this fully multilingual operation system coupled with a multilingual development tools still has problems.
Before I go into detail about the error, let me explain how I got the various translations into the system. First an Excel spreadsheet is set up with a separate column for each language and the text for each phrase is entered in the rows. This is sent off to our translators around the world and comes back via an attachment in email. These translations are combined into a master spreadsheet which is then imported into a table in a Microsoft SQL Server 2005 database. This database is used to replace any text on the web page. The Dataset on the web page is a select query returning just one record containing the text phrases in the desired language and the relevant column is displayed on the page. It is worth noting here that it is a good idea to forget your naming conventions for database field names, but instead pick something that gives you an idea of the text that field contains, as this will make it so much easier to understand your page in the future. For example:
This is easier to make sense of what text goes where:
<input id="Button1" type="button" value='<%=(RsText.Fields.Item("Request stock list with prices by email").Value)%>' />
Rather than:
<input id="Button1" type="button" value='<%=(RsText.Fields.Item("btnTxtEmailReq").Value)%>' />
Get the idea ?
So far so good, both Excel and SQL Server seem to fully support all the characters we need. The ASP pages seems to also, although there is the occasional ‘drop out’ of certain accented characters, these being replaced by their non-accented cousins, something which I (and the client) are happy to live with. However although most of the ASP .NET Framework 3.5 SP1 controls are quite happy, the button control seems not to like the Polish ó character and probably others as well, the same applies to the Grid View control whilst the label control is happy to display it..
A button rendered in ASP, not all accents are correct many have been dropped but it is readable
A button rendered in ASP .NET 3.5 SP1 supposedly fully multi lingual
I have asked Microsoft about this, but am still waiting for any reply from them. To say ASP .NET fully supports the major European languages seems to be a bit of a joke. The older ASP is happy enough it seems. Perhaps I should go back to Dreamweaver and an easy life!
Article by: Mark Newton
Published in: Mark Newton