While examining the ASP and HTML code, check for nested include files. If your application relies heavily on nested include files, you may have to reverse engineer the dependencies of the routines. Additionally, if the include structure has not been normalised, you may find name and functionality duplication when organising your application into a coherent global structure. Ideally, all your utility classes will be contained in separate ASP files (or even better as COM objects). Similarly, global variables should be contained in a single ASP file rather than distributed throughout the application. Vigilant use of sessioning
Beyond server controls, .Net offers new features for enhancing the scalability of Web applications. One of these features is a distributed sessioning model that makes session data available over multiple application servers in a Web farm. No specific modifications to the code base are required for distributed sessioning, although the mechanics involved require using SQL Server to store the application state. Depending on the quantity and type of state data, application performance could be impacted. To take advantage of this capability without incurring performance degradation, carefully evaluate your current session implementation -- especially the quantity, type, and structure of maintained state information. During the migration, tightly control what goes into sessioning. Combine application affinity techniques and failover modes to limit the required state information. Structured error handling design
A new structural change brought on by VB.Net is the introduction of the Try, Catch error handling mechanism that is familiar to Java programmers. The On Error and related statements are still supported in VB.Net, but best practices dictate moving to the new, structured error handling mechanism. To take advantage of this new error-handling feature, a detailed understanding of the current and anticipated application error processing for your application will be needed. It's time to get started
Having a well-positioned application code base can mean the difference between a successful, seamless migration and a project mired with unforeseen difficulties. Examine your system for .Net portability issues and accepted best practices. With luck or prescience, you will find the presentation tier coded in a single language like JavaScript, and the application tier coded in VB, C#, or C++. Ideally, your presentation tier is well organised with little logic of its own and no embedded SQL; and your application tier encapsulates coded business rules through COM objects. At the database level, in an ideal world, you will find stored procedures invoked by the application with COM. .Net promises many immediate advancements, and like most Microsoft applications, the new platform will only get better. Check your systems now and prepare for the inevitable call for the new functionality available in .Net. Even if your system does not represent the ideal migration candidate, .Net will most likely offer enough advantages to support any necessary rework. At the very least, the chance to migrate to a new platform offers an opportunity to fix longstanding problems in your application. So seize the moment, dig into the code, and get .Net ready.
For a weekly round-up of the enterprise IT news, sign up for the
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
