This is the third and final installment in a three-part series. In the first installment (.NETDJ, Vol. 2, issue 9), I covered general conversion issues, in the second installment (Vol. 2, issue 10), I finished general conversion issues, and covered issues associated with database conversions. In this final installment, I will cover ASP Web page conversions, converting to VB.Net 2005, converting to C#, and finally, I will cover some arguments for converting.

Converting ASP to ASP.NET
Converting from ASP to ASP.NET is probably the easiest of all .NET conversions because ASP Web pages can be used side-by-side with ASP.NET Web pages, meaning the conversion can be done on a page-by-page basis. This is because the ASP and ASP.NET engines, like many things in .NET, can run side-by-side. The server knows which engine to pass the page to because ASP pages have a .asp extension, and ASP.NET pages have a .aspx extension.

One exception to this is that ASP pages and ASP.NET pages are considered different applications in different sessions, so session variables and other session and application states cannot be shared. There are two solutions to this problem. The first is to convert all pages that share state information to ASP.NET as a group. The other option is to use a different method to share the information, such as a database, or the data can also be posted from one page to another, regardless of whether the pages are written in ASP or ASP.NET. Details on how to share states using databases can be found at http://msdn.microsoft.com/asp.net/using/migrating/ default.aspx?pull=/library/en-us/dnaspp/html/converttoaspnet.asp.

Another issue that complicates conversions is that while a single ASP page can use more than one server-side scripting language, each ASP.NET page is limited to a single server-side scripting language. Allowing mixed scripting languages was required with ASP because of limitations with scripting languages such as incomplete support for COM objects in JScript; this occasionally required adding VBScript to pages that otherwise would have been written completely in JScript. In ASP.NET, these limitations in JScript have been removed, making mixed scripting languages unnecessary in most cases. This should make JScripters happy, but it may generate extra work during the conversion process. Because client-side script, even that generated by server-side script, is executed on the client, it doesn't need support from ASP.NET and so is still allowed in ASP.NET.

Because ASP and ASP.NET pages can coexist, the simplest conversion strategy is to just start writing new pages in ASP.NET.

The next step is to just change the extension of a page from .asp to .aspx; because ASP.NET was designed to be compatible with ASP, simple ASP pages may run as ASP.NET pages without change.

Because ASP scripts are interpreted, and ASP.NET scripts are compiled, any scripts used by the page will typically run much faster without any other changes.

Doing the ASP Conversion
ArtinSoft, the company that wrote the VB6 to VB.NET converter for Microsoft, has also written an ASP to ASP.NET converter for Microsoft that can be downloaded from www.asp.net/MigrationAssistants/Default.aspx?tabindex=0&tabid=1 . Downloadable from the same page is a PHP to ASP.NET converter, and information on using the Java Language Conversion Assistant (JLCA) to convert JSP pages to ASP.NET pages; they also have a PL/SQL (Oracle) to T-SQL (Microsoft) database conversion assistant that can also be downloaded from their Web site. Their home page is at www.artinsoft.com; from their download link, you can get access to more help on the assistants, and several useful white papers. ArtinSoft is one of several companies that will also do the complete migration for you, or consult in specific migration issues for a price.

Converting from ASP to ASP.NET can be broken down into three parts, converting old scripts to the new scripting languages, addressing new limitations in ASP.NET, and taking advantage of new .NET features.

JScript.NET is backwards compatible with JScript, so JScript scripts can be used with ASP.NET without modification; however, JScript.NET has a number of enhancements such as namespaces, enumerations, constants, conditional compilation, and typed variables that can be taken advantage of; other .NET languages can also use JScript.NET objects.

There is no VBScript.NET; .NET uses full-blown VB.NET, so VBScript will need to be converted to VB.NET. This is similar to converting VB6 to VB.NET and using the ASP.NET conversion assistant to convert VBScript is similar to using the VB upgrade assistant to convert from VB6 to VB.NET. Most of the information in the first two parts of this article will apply here; the main difference is that some changes I recommend making before the conversion, such as declaring all variables and giving them explicit types, are not valid in VBScript and must be made after the conversion.

As with the VB6 conversion, parts of the ASP pages that the assistant cannot convert will be marked for manual conversion, and a conversion report listing unresolved issues will be attached to the project.

Because VB.NET has so many advances over VBScript, such as supporting objects and inheritance, once the conversion is made there will be lots of opportunities for improving the code. As with JScript, VB.NET is compiled and able to interoperate with other .NET languages.

In addition to changes in scripting, many ASP pages will need some changes to become ASP.NET pages; the conversion assistant will make most of these changes.

One simple change is that since the extension for converted pages changes from .asp to .aspx, references to other pages from within a page will require the extension on the reference to also be changed.

ASP, like VB6, does not require variables used by a page to be declared or typed, but ASP.NET does. The assistant adds declarations for undeclared variables, and when it does, the assistant also examines how untyped variables are used in the code, and tries to declare the variable as the correct type.

ASP.NET has different limitations from ASP on what type of code can appear within the bounds of which tag type. The conversion assistant will move code around and add tags as needed to match the new ASP.NET rules. It will also move variable declarations around to match new rules about how variables are scoped. An example of this is that in ASP subroutines, variables can be declared in render tags (<% %>), but in ASP.NET, they must be declared in script tags (<script> </script>). There are also other changes the assistant will make to reflect changes in tag syntax between ASP and ASP.NET.

With the sweeping changes between ASP and ASP.NET, it is not surprising that there are some major parts of a Web application that the conversion assistant cannot convert. For instance, the assistant can convert simple rendering functions, but it is unable to convert many of the more complex rendering functions. It will however, mark the code for manual conversion. Also, as mentioned above, any ASP page that uses multiple server-side scripting languages will need to be modified either before or after conversion to use a single scripting language; this will likely require converting some scripts to a different language. Later in this article I will cover some tools that can help convert between some .NET languages.

Possibly the most difficult part of the ASP to ASP.NET conversion will be security issues. In ASP, security was provided by IIS impersonating the user accessing the page. ASP.NET has much richer security options, giving the designer far more control. Covering security issues is beyond the scope of this article, but a nice overview of ASP.NET security can be found at www.asp101.com/articles/cynthia/authentication/default.asp, and more details can be found in the links on http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/vbcon/html/vboriSecurityForASPNETWebApplications.asp.

One advantage to converting to ASP.NET is the addition of new controls and control types. In addition to the HTML controls available in ASP, ASP.NET adds ASP.NET validation and user controls.

ASP.NET controls have several advantages over HTML controls. The first advantage is that ASP.NET controls can dynamically generate either HTML or JScript code that is compatible with the user's browser, for an example of this, see www.developerfusion.com/show/2074/3/. Another advantage of ASP.NET controls is that they can be bound to data similar to the way Winform controls can be bound to data. The controls properties can be bound to variables, properties of other controls, collections, or data sources including XML recordsets.

Validation controls do exactly what their name implies; they are attached to input controls and validate data entered into the controls. They support most common validation scenarios, including ranges and patterns, they can verify that required fields are filled out, as well as executing custom validation logic written by the Web developer. Details on what validations are supported can be found at http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/vbcon/html/vbcontypesofvalidation.asp.

User controls allow even beginning Web developers to create new controls aggregated from other controls. An example of such a control would be a login control that combined a pair of labels ("User Name" and "Password") with a pair of textboxes, and related validation code. These would all be combined into a single control that could easily be dropped into multiple Web sites.

Does this example make you wonder why Microsoft did not include a login control as one of the standard ASP.NET controls? Well they did, it just took them until version 2.0 to do it! As big a leap forward as ASP.NET is, ASP.NET 2.0 is an even bigger leap, and the poster boy for version 2.0 is the new login control. Everyone who has seen the new .NET 2005 login control loves it. This control includes all login related code including the login control itself, authentication, adding new users, and handling the database holding login information (including adding new members to the database). It is simply amazing how much this control handles, how well it handles it.

ASP.NET 2.0 also has even more security features than the current version. Zak Ruvalcaba has a nice Web page devoted to ASP.NET 2.0 security, including the login control, at www.sitepoint.com/article/asp-net-2-security; also, a link off that page allows you to download four sample chapters of his book on ASP.NET 1.0.

Another great ASP.NET 2.0 feature is the ability to use master Web pages; these are like base classes for programmers. You can, for instance, create a standard master Web page with headers, logos, and custom navigation panes, and then use that page as the base for all of your other pages, giving them all the same look and feel. Unlike ASP, you can then change the derived pages without the changes affecting the master page.

More information on ASP.NET version 1.0 and 2.0 can be found at http://msdn.microsoft.com/library/, look through the table of contents on the left for areas of interest. ASP.NET information can be found under several different heading, so it pays to scout around. Some of my favorite sections were under .NET Development/Web Applications/Technical Articles.

A final advantage of ASP.NET is that by using either Mono (www.go-mono.com) or Portable.NET (getdotgnu.com), ASP.NET pages can be use with Apache on Linux.

Converting to VB.NET 2005
The VB6 to VB.NET upgrade assistant was greatly improved between VB.NET and VB.NET 2003, and I expect the VB.NET 2005 version will again show great improvements. I have only had an early beta version to test, and have not had very much success with it, possibly because I have not had a chance to work with it very much. In part 1 of this series I gave the http://lab.msdn.microsoft.com/express/vbasic/default.aspx URL where anyone could download the VB.NET 2005 Beta. There is now a newer, experimental (unstable) version available from the same Web site; at the time I wrote this, it had just been posted, and I had not had a chance to download it. It can be downloaded from the bottom of the page; the original, more stable beta can still be downloaded from the top of the page.

Other Conversions
In this section I will cover interoperation between .NET languages and converting between VB.NET, C#, and other languages.

In most cases, once VB6 has been converted to VB.NET, it will not be too difficult to convert it to C#. If the plan is to convert, and not rewrite, it makes sense to convert to VB.NET first.

Microsoft makes a big deal about .NET languages being compatible, even to the point of a class in one language being usable as a base class in a different language, such that some methods in a class can be written in one language, and other methods in the same class can be written in a different language. Well, I have seen the demo and it can work; but be aware that your mileage may vary. There are two issues that can cause problems with interoperability between .NET languages. The first is that for full interoperability, the code in both languages typically needs to be CLI compliant. The second issue is that language behavior can cause problems.

Most, if not all .NET compilers extend the core CLI in one way or another, but for .NET languages to be able to interoperate completely, these extensions cannot, in most cases, be used. The details of this are far beyond the scope of this article, but some examples of these extensions are optional parameters (VB.NET), multiple inheritance (C++), unsafe code (C#, C++), and dynamic languages (Python, Pearl, etc). Languages can also behave differently, for example, VB.NET resolves overloaded functions differently that C#. That is not to say that these languages cannot interoperate, it is just that trying to get different .NET languages to interoperate can be difficult, and is subject to obscure bugs.

Borland has Delphi for .NET, which targets the .NET CLI instead of Windows or Linux. When compiling older Delphi code, it marks places where there are issues such as unsafe code. Delphi 8.0 uses .NET remoting for its data services. Lars Johansson has also created a Delphi to C# converter (it also converts VB6 and VB.NET to C#) at http://w1.311.telia.com/~u31115556/desc/programs.htm#BabbelFisken. The page is in German, as are the sample conversions, but the program's interface is in English.

Several tools and Web sites help convert between C# and VB.NET. None of them are perfect, and some support different features than others. For example, there is a community project at www.codeproject.com/csharp/gbvb.asp that does a fairly good job, but can't convert VB code with constructs like "thing(x)", because it does not know if it is a function (C# thing(x)) or an array (C# thing[x]). There is a commercial VB.NET to C# converter at www.vbconversions.com that claims to have converted the 101 sample projects from Microsoft listed at www.microsoft.com/downloads/details.aspx?FamilyId=08E3D5F8-033D- 420B-A3B1-3074505C03F3&displaylang=en , as well as all the VB.NET sample programs that come with Visual Studio 2003. They have a trial version that is the same as the full version, but limited to 600 lines of VB.NET code. The unlimited version is only $149.00 (U.S.).

The Converting Debate
In my opinion, one of the most important reasons for upgrading is to get access to better tools. Each version of Visual Studio has made big improvements in programmer productivity. Even though VS2003 is a minor upgrade from VS2002, the intellisense and auto-complete in VS2003 is so much better than in VS2002, that when I need to work with VS2002, I save a copy of the project file and upgrade to VS2003; when I am done, I copy the old VS2002 project file back over the VS2003 project file (the changes to C# and the .NET Framework class are small and easy to avoid or correct). Using the old VB6 editor that does not even support scroll mice feels like going back to an old DOS editor. I expect that VS2005 will continue this tradition in general, and with Visual Source Safe (VSS) and Microsoft Team in particular. VSS has not had a significant update since VB4; VS2005 has a completely rewritten version of VSS.

The biggest change is that SQL Server is replacing the old proprietary database; this should improve performance, reliability, and maintainability of the code repository. Microsoft Team is a complete application life cycle framework, similar to packages sold by third-party vendors such as Rational Software. Microsoft has mostly stayed out of this market to avoid competing with Rational, even to point of selling Rational the old Microsoft Test product. Now that IBM has bought Rational, Microsoft is releasing its own products integrated with VS2005. Team will include application and database modeling, bug tracking, workflow, and a new UML like tool. Those staying with VB6 will not have the advantage of any of these tools without buying third-party equivalents; even those will be less capable than the same third-party offering for .NET.

Summary
This completes this series on converting VB6 to VB.NET. The transition is not that difficult, the results tend to be good, there are a lot of tools, books, and articles to help make the transition, and the rewards are great. Microsoft has put VB6 into maintenance mode - it is time to do the same with VB6 code, and make the move to .NET.