Pre-migration Strategy

Snoops

   

 
Migrating to .NET: A Pragmatic Path to Visual Basic .NET, Visual C++ .NET, and ASP.NET
By Dhananjay Katre, Prashant Halari, Narayana Rao Surapaneni, Manu Gupta, Meghana Deshpande

Table of Contents
Chapter 5.  Migration Approach for ASP to ASP.NET


When porting an ASP application to ASP.NET, the developer needs to decide how much time should be spent incorporating the new features of ASP.NET into the existing ASP application. Changing an ASP page's file extension from .asp to .aspx and correcting for some syntactical changes is usually enough to get an ASP page working as an ASP.NET page. Such a migration, although it can be completed quickly, does not take advantage of the new features of .NET, such as ASP.NET Web controls, ADO.NET, and the .NET Framework classes. Hence, it is advisable to consider the trade-offs between time and functionality because although a more thorough migration may take more time, your finished ASP.NET pages will be readable, maintainable , and have more features.

To minimize the migration efforts, a few pre-migration changes follow. They are to be made to the existing ASP Web application and include changes to be made to the existing code as well as some security settings. These code changes can also be viewed as good practices to be followed during the development of any ASP Web application.

Guidelines for Code Changes

  • Use Option Explicit and ensure that all the variables are declared to their respective data types.

  • If unsure of the data type, declare the variable as object because object is the default data type under the .NET Framework and the variant data type (a universal favorite) is no longer supported.

  • Use parentheses for all method calls including ResponseWrite .

  • If there are functions on the page written within the <%%> delimiters, replace them with <SCRIPT runat =server></SCRIPT> tags. Also, Render functions like the one shown in the code sample below are no longer supported and must be avoided.

     <%sub printHello()%>     <H2>Hello World!</H2>  <%end sub%> 
  • When developing an ASP application, the business logic should be ideally implemented in the middle- tier (COM or COM+). Because migration of COM to .NET requires minimum efforts, the investment in COM will not be lost while migrating the application to .NET. For more details on interoperability refer to Chapter 10.

  • Make use of code separation techniques by isolating the presentation layer from the application logic. This can be done by separating the HTML and script using include files or by using classes consisting of functions and methods inside the body of the class in the script, thus ensuring code reusability.

  • Nested include files (include files that include other files) should be avoided. In such a case there is probably some global variable defined in one include file and used in the others. In ASP.NET, global variables and functions are written in class files, which ensure global access.

  • Because the .NET Framework is based on the concepts of object-oriented programming (OOP), choose a scripting language that supports OOP. JScript is the best example. Use the class structure to enclose methods; this will ensure a smoother migration.

  • If VBScript is the language of choice, make sure to use early binding wherever possible.

  • Avoid mixing languages on a single page. An ASP page coded partly in VBScript and partly in JScript will be difficult to migrate. In general, this is poor programming practice. This becomes a migration issue because in the new compilation model we can define only one language per page. However, client-side scripting can continue using multiple languages.

  • ADO is supported under the .NET Framework; hence the migration efforts can be minimized by using early binding while using objects of the ADO. Early binding will also avoid the use of the keyword set , which is no longer supported under the .NET Framework.

  • Because default properties are not supported, it is recommended that the full property must be specified; for example, rs.fields ("name").value should be used instead of rs (" name ").

  • Null is no longer supported; hence variables should be set to nothing instead of null while deinitializing them.

  • Free resources explicitly by calling close methods wherever possible. Although the .NET Framework has a developed garbage collection techniques, we don't know when the resources actually get freed, and hence it is always advisable to destroy objects or remove them from memory when not in use.

  • The preferred platform for developing ASP applications should be Windows 2000 because it eliminates the use of MTS while developing COM.

Security Settings

ASP applications rely heavily on IIS for providing security to the Web applications. The primary function of IIS is to download ASP and HTML pages to the client browser under controlled access. To do so, the application must be able to identify the user requesting control of the resources. Authentication is the act of validating a user 's identity. IIS provides certain authentication schemes such as:

  • Anonymous

  • Basic

  • Digest

  • Integrated Windows Authentication

  • Client-certificate mapping

Out of these, anonymous authentication is enabled by default. Although classified as a type of authentication, it does not actually perform any client authentication. Instead, IIS provides stored credentials to Windows using a special user account, IUSR_machinename . By default, IIS controls the password for this account. Whether or not IIS controls the password affects the permissions the anonymous user has. When IIS controls the password, the client is authenticated against the Windows login name and password without the password being actually provided. When IIS does not control the password, it performs a local Windows logon, following which IIS impersonates the account. This gives maximum access permissions to the anonymous user, namely, IUSR_machinename .

MAKING CHANGES TO IIS SECURITY SETTINGS

The following are the steps required to change IIS settings:

  1. Open the Internet Information Services for Windows 2000 by clicking on Start Programs Administrative Tools Internet Services Manager. See Figure 5-2.

    Figure 5-2. Internet Services Manager for Windows 2000.

    graphics/05fig02.jpg

  2. Under Default Web site select the required Web application as shown.

  3. Right-click and go to Properties. Select the Directory Security Tab. See Figure 5-3.

    Figure 5-3. Directory Security tab on properties of default Web site.

    graphics/05fig03.gif

  4. Click on Edit for anonymous access and authentication control. Verify that the anonymous access option is checked and click on Edit for anonymous access. See Figures 5-4 and 5-5.

    Figure 5-4. Checking the anonymous access option.

    graphics/05fig04.gif

    Figure 5-5. Edit of anonymous access.

    graphics/05fig05.gif

  5. Uncheck the option Allow IIS to Control Password and clear the Password field. See Figure 5-6.

    Figure 5-6. After editing the anonymous access option.

    graphics/05fig06.gif

  6. Click OK and finally click Apply to apply the changes just made. See Figure 5-7.

    Figure 5-7. Applying changed settings.

    graphics/05fig07.gif

MAKING CHANGES TO SYSTEM SECURITY SETTINGS

ASP.NET pages are executed by the aspnet_wp.exe worker process, which runs under the user ASPNET (aspnet_wp account). This user belongs to a group , Users, which does not have certain access rights. As a result, the ASP.NET code runs with reduced permissions on the system, and administrators may have to grant the ASPNET account certain security ACLs explicitly to use certain Windows features. This can be noticed in a scenario where the code for writing to a file, say a certain XML file, works perfectly well in ASP but throws an error saying "Access Denied" after migrating it to ASP.NET. This can happen because the ASP.NET user may not have write permissions for that particular file. File write permissions can be granted at the individual directory or file level. Also, there can be other scenarios such as connecting to a database file over a network, using the SMTPMail service to send emails, creating new EventLog categories dynamically, or reading the registry or IIS metabase where the user will have to be granted rights explicitly. Instead of granting rights at the directory or file level, the user can be made to belong to a group that already has such rights.

The following modifications make the ASPNET user belong to group Administrator on the server. This makes ASPNET run as an administrator on the server, and it has all the administrator access rights. This can also pose certain security threats; hence, these modifications are not mandatory.

Another way of configuring the process identity using machine.config is described later in this section. Note : The ASPNET user will be created on the server only if ASP.NET is installed.

  1. Open Computer Management for Windows 2000 by clicking on Start Programs Administrative Tools Computer Management.

  2. Click on Local Users and Groups and under Users select user ASPNET as shown in Figure 5-8.

    Figure 5-8. Computer Management for Windows 2000.

    graphics/05fig08.gif

  3. Right-click on ASP.NET and go to Properties. Select the Member Of tab. See Figure 5-9.

    Figure 5-9. Member Of tab on Properties of user ASPNET.

    graphics/05fig09.gif

  4. Click on Add. Select and Add Administrator from the list displayed. See Figure 5-10.

    Figure 5-10. Making ASPNET a member of administrator group on local machine.

    graphics/05fig10.gif

  5. Click OK to apply settings.

  6. Repeat the above procedure for the anonymous user IUSR_ machinename. See Figure 5-11.

    Figure 5-11. Select user IUSR_machinename.

    graphics/05fig11.gif

CONFIGURING PROCESS IDENTITY

The identity for the ASPNET worker process is the ASPNET account, as described earlier. This can be configured in the <processmodel> section of the machine.config present in the Config subdirectory of the installation root directory. The userName and password attributes control the identity of the process. The default values for these attributes are as follows :

 <processModel userName="machine" password="autogenerate" /> 

The value machine for attribute userName indicates that the process runs under the ASPNET account. This, as we know, is a less-privileged account, but it is suitable for most Web applications.

If the process requires more access rights, the attribute userName can be set to System . This causes the ASP.NET worker process to run under the same identity as the Inetinfo.exe . The Inetinfo.exe runs as the System identity by default. When the ASP.NET worker process is configured to run under System , it can access all of the resources on the local machine. On computers that are running Windows 2000 or Windows XP, the System account also has network credentials and can access network resources as the machine account.

To configure the process to run under the System identity, change the <processmodel> section as follows:

 <processModel userName="system" password="autogenerate" /> 

Snoops

   
Top


Migrating to. NET. A Pragmatic Path to Visual Basic. NET, Visual C++. NET, and ASP. NET
Migrating to. NET. A Pragmatic Path to Visual Basic. NET, Visual C++. NET, and ASP. NET
ISBN: 131009621
EAN: N/A
Year: 2001
Pages: 149

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net