Docstoc

Migrating Win32 Applications to Windows Server 2003

Document Sample
Migrating Win32 Applications to Windows Server 2003 Powered By Docstoc
					Migrating Win32 Applications to Windows Server 2003

Microsoft Corporation
Published: November 2002




Abstract

This white paper introduces concepts for migrating Microsoft® Win32® applications to Microsoft
Windows® Server 2003 and the Microsoft .NET Framework. This includes applications such as Visual
Basic®, 32-bit Windows-based applications, and Web applications written using ASP. The paper
discusses pros and cons of migration as well as tips on the process. The paper also contains a
number of links to other technical papers on this subject.
This is a preliminary document and may be changed substantially prior to
final commercial release of the software described herein.
The information contained in this document represents the current view of
Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information
presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES
NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE
INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the
user. Without limiting the rights under copyright, no part of this document
may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the
express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights,
or other intellectual property rights covering subject matter in this
document. Except as expressly provided in any written license agreement
from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual
property.
© 2002 Microsoft Corporation. All rights reserved.
Microsoft, SQL Server, Visual Basic, Visual Studio, Windows, and
Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be
the trademarks of their respective owners.
                                                                                             Microsoft® Windows® Server 2003 White Paper




Contents

Introduction .................................................................................................................................... 4

   Why Migrate Applications to the Windows Framework?.............................................................. 4

   Enabling Application Migration ..................................................................................................... 5
Migration Planning ........................................................................................................................ 5

   Scalability and Performance Requirements ................................................................................. 6

   Application Architecture ............................................................................................................... 6

      Web (Client/Server) Applications ............................................................................................. 6

      Rich Client Applications ............................................................................................................ 7

      Stand-Alone Windows Desktop Application ............................................................................. 7

   Code Quality and Design ............................................................................................................. 7

   Size Matters ................................................................................................................................. 8

   Other Technological Considerations ............................................................................................ 8
Application Upgrade Options ....................................................................................................... 8

   Rewriting ...................................................................................................................................... 9

   Complete or Partial Upgrade ....................................................................................................... 9
Performing the Migration ............................................................................................................ 10

   Visual Basic 6 Applications ........................................................................................................ 10

      Visual Basic .NET Upgrade Wizard ....................................................................................... 10

   ASP to ASP.NET........................................................................................................................ 13

      Upgrading ASP Applications to ASP.NET .............................................................................. 14

   Migrating C++ Applications to Managed C++ or C# .................................................................. 22
Conclusion ................................................................................................................................... 23
Related Links ............................................................................................................................... 23




                                                                Page 3 of 23
                                                                Microsoft® Windows® Server 2003 White Paper




Introduction
Managing applications and the systems they run on has always been difficult for system and
network managers. This issue is not limited to a particular operating system, but results from the
complexities inherent in deploying and maintaining applications. Migrating applications to a new
technology such as Windows Server 2003 and the .NET Framework present an opportunity to
solve some of these issues.

Migration might involve the simple physical process of copying existing files for an application on
to a new server, or it might entail rewriting some or all of an application’s code base. This paper
explores different strategies for migrating Win32 applications to the Windows Framework to take
advantage of the features of, and ensure compatibility with, the Windows Server 2003 platform.
We will look at simply moving applications and running them side by side with new .NET
applications. We will also look at migrating the code of an application and turning it into a totally
.NET application.

As other whitepapers illustrate, there are often benefits to migrating applications to Windows
Server 2003, including improved performance and manageability. Existing Win 32 applications
can be migrated to the .NET Framework and to Windows Server 2003 to take advantage of
scalability, reliability, manageability, security, and deployment features. This includes migrating
Visual Basic 6 (VB 6) applications to Visual Basic.NET (VB.NET), ASP applications to ASP.NET,
and migrating C++ or other Win32 applications to use features of the .NET Framework and
Windows Server 2003. Win32 applications written with non-Microsoft tools can also often be
migrated to Windows. Even if you continue to use non-Microsoft development tools, you can still
migrate your applications to Windows. For example, Delphi and Oracle both support .NET
development and migration.

Why Migrate Applications to the Windows Framework?

The Windows Framework running on Windows Server 2003 simplifies the integration of
applications and the development of new applications while substantially enhancing the features
that can be built into an application. Some of the many benefits of the .NET Framework and
Windows Server platform include:

   Windows-compliant languages and the Visual Studio .NET development environment allow
    developers to capitalize on extensive libraries of functions that handle the plumbing and
    housekeeping chores of many common tasks, such as those required when creating and
    accessing XML Web Services. Thus, development is vastly simplified compared to older
    development technologies.

   Developers can easily add performance monitors and management tools to their applications
    that administrators can use to manage those applications.

   Applications are easier to deploy and update on both servers and client workstations.

   Version management is much more explicit and avoids “DLL Hell.” Side-by-side deployment
    allows multiple versions of a shared component to be installed and executed simultaneously.




                                            Page 4 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




   Enhanced security for applications and protection of servers from errant applications (process
    isolation).

   Infrastructure needs like authorization, authentication, and messaging are built into Windows
    Server 2003. Furthermore, Windows offers scalability support that ensures your application
    can scale up and out, using features such as Network Load Balancing and Clustering
    Services, as described in the Scalability whitepapers.

   New .NET languages are built from the bottom-up for distributed applications

   There are substantial performance increases for most applications, and in particular for
    ASP.NET-based applications compared to prior releases of the Windows Server OS.

   Enhanced application portability due to the Common Language Infrastructure (CLI) and
    interoperability (XML Web Services). The CLI ensures that code can be mixed among, and
    reused with any .NET-compliant development language, such as C#. XML Web Services
    allow disparate applications to communicate via a standard interchange mechanism using a
    well-defined common format.

Enabling Application Migration

Microsoft offers a rich set of tools that simplify migration of applications to the Windows Server
2003 operating system while remaining compatible with application features from past Windows
servers. The .NET architecture is an end-to-end solution comprising the tools, servers, .NET
building block services, device software, and user interface components needed to develop and
deliver next-generation applications.

The components of Windows Server 2003 that are important to migration include:

   Visual Studio .NET (VS .NET), a robust development environment for rapid application
    development with a complete suite of tools, an upgrade wizard, and an installer wizard.

   The .NET Framework provides thousands of classes to implement most commonly needed
    components, including database connectivity (through ADO .NET) and XML Web Services.

   A suite of administrative and productivity tools and technologies including Messaging
    (MSMQ) and Active Directory (AD) services.

   Standard user interface components for Web-based applications (Web Forms) and rich
    Windows-based applications (Windows Forms).

   Support for side-by-side execution of ASP and ASP.NET Web-applications.

   Integration between COM- and .NET-based DLLs through COM InterOp.

   Integration with applications through Host Integration Server, XML Web Services, MSMQ,
    and other technologies.


Migration Planning
You should evaluate the specifics of your business situation and needs before deciding the best
path to upgrade existing applications to the .NET Framework. In performing the cost/benefit




                                           Page 5 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




analysis, you must consider whether to upgrade or rewrite the entire application or part of the
application (and which parts to upgrade and which to leave as is).

The answer depends on your application’s architecture, components, and business requirements.
The pain and cost in upgrading depend on how closely the old architecture maps to the newer
.NET constructs. If the match is poor, the application may be a good candidate for rewriting or
leaving as is, depending on the benefits associated with migrating to .NET.

For example, a Web-based application with a simple architecture that requires high availability
and responsiveness would be a good candidate for upgrade. However, an application that is
form-based, has low user volume, relies on many unmanaged API calls, and consists of code that
is old or has been frequently modified would be a good candidate for a rewrite (or leaving as is).
When considering rewriting an application from scratch, weigh not only the cost in upgrading the
existing code but the benefit in transforming it to provide or use XML-based Web Services or
other new technologies.

It doesn’t make sense to invest heavily in upgrading an application that is at the end of its useful
life unless doing so reinvigorates it. Therefore, you should time your upgrade to coincide with,
say, the next generation of the product rather than upgrading an obsolete version. That said, you
should consider proceeding in two phases, first upgrading the code to the .NET Framework and
then adding features once you’ve successfully ported the code. Consider concurrent deployment
of old and new versions so that downtime is minimized or eliminated altogether. The new system
should be tested and debugged before the old application is scrapped in order to ensure a
smooth transition. The Enterprise edition of VS .NET includes numerous testing and validation
tools to assist with reliability and functional testing.

The following sections outline other considerations in determining a .NET upgrade strategy.

Scalability and Performance Requirements

If scalability and performance are important to your application, it may benefit significantly from
being upgraded to, or rewritten from scratch, using the .NET Framework. This is particularly
relevant for ASP and ADO applications. For example, the ADO .NET data access object model
takes advantage of lightweight XML, and the new Data Reader is optimized for speed. ASP.NET
is also now compiled and has new caching and improved state management for deployment
across web farms.

Because of the architectural changes brought about in .NET, it is possible for a rewritten
application to realize a five-fold increase in performance from an ASP/Visual Basic 6.0/ADO
application, as measured in maximum requests per second.

Application Architecture

An application’s architecture will largely determine if and how to upgrade it. Three broad
categories of applications are discussed below for illustrative purposes.

Web (Client/Server) Applications
Two-tier Web applications are characterized by an HTML client, usually written in ASP using
VBScript and data access using ADO that connects to a data store. If not written in ASP, the
application’s middle tier may comprise multiple layers of business logic written in VB 6, C++ or




                                           Page 6 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




other languages. By nature, these applications often require high performance and scalability to
support hundreds or thousands of concurrent users across the Internet or intranets.

Not only do such applications tend to benefit greatly from upgrading to the .NET Framework, they
are also relatively simple to upgrade because of easy mapping between legacy and .NET
technologies. ASP code can, with some effort, be converted to ASP.NET using a managed
language such as C# or VB .NET. Middle-tier components written in VB 6.0 can be upgraded
using the Visual Basic .NET Upgrade Wizard included with Visual Studio .NET. The data access
layer can be converted to ADO .NET, and any third-party components can be accessed via COM
InterOp.

Rich Client Applications
Rich client applications differ from client/server Web applications in that they move some
processing and business logic to the client. Such an application might consist of a client written
using Visual Basic 6 Forms and a connection to a data store such as SQL Server. Like Web
applications, these applications may also have middle-tier COM components with business logic
and some type of data-access layer.

Windows client applications may contain ActiveX controls, COM components, or third-party
controls. Unless their design is fairly straightforward, such applications are more difficult to
upgrade to the .NET Framework. Although upgrading the middle-tier components is much the
same, upgrading the client may prove more difficult than the relatively simple transition from ASP
to ASP .NET for Web applications.

Windows client/server applications will garner performance and scalability benefits from a middle-
tier upgrade. Migrating the front end will allow developers to take advantage of powerful new
features such as the auto deployment options that can dramatically lower the TCO of an
application.

Stand-Alone Windows Desktop Application
Windows stand-alone applications such as games, graphics programs, controls, and utilities can
also be upgraded. Even if an application doesn’t require high performance or scalability, and if it
works fine as an unmanaged application, the other benefits of the .NET Framework would be the
deciding factor in whether to upgrade. For example, if you’d like to upgrade a game from a
standalone application to a multiplayer internet-based application, .NET offers substantive
benefits. There are also dramatic benefits such as GDI+, the .NET graphics rendering engine
which supercedes the older GDI engine, that you can take advantage of for high performance
graphics operations. This allows game developers to build powerful applications that were only
possible with low level coding in the past. See “GDI+ Graphics.”

Code Quality and Design

Code quality affects your upgrade strategy; especially with VB 6.0 because of the substantial
amount of VB code in production today and the improvements to the language with VB.NET. The
rough rule of thumb is “upgrade good code and rewrite bad code.” That is, upgrade good code by
making as few changes as possible to ensure compliance or satisfactory integration with the new
environment. Rewrite bad code from scratch if a more subtle upgrade is impossible, or if the code
needed to be rewritten (say, to fix major architectural flaws or bugs) even if it wasn’t being
migrated. In other words, don’t bother trying to salvage bad code that should logically be
discarded.




                                           Page 7 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




For example, if the VB 6.0 application does not have a modular design or uses convoluted
programming constructs, it may be less costly to rewrite it than to attempt an upgrade. If an
application is designed in a modular fashion, changes in data types or behaviors of functions or
controls are less likely to break the application; debugging and repair of the components is likely
to be far less difficult. If the code does not contain legacy syntax such as Def<type>, Computed
GoTo/GoSub, GoSub/Return, Option Base 0|1, VarPtr, ObjPtr, StrPtr, and LSet, migration to
VB.NET will be easier. The Upgrade Wizard will actually tag many of these items for you, thus
assisting you in analyzing your application.

Size Matters

Code size (i.e., the number of lines of code that need to be migrated) should be taken into
consideration when screening applications to upgrade. Don’t underestimate the cost of upgrading
or rewriting a large code base, if only because they take longer to understand fully and have more
places where problems can hide. Programs or submodules containing fewer lines of code are
both easier to upgrade and less costly to rewrite, should it become necessary to abandon the
upgrade path.

Larger code bases will take more time to upgrade, and if they aren’t modular, may be difficult to
upgrade in parts. Everything takes longer the first time, until developers become familiar with the
new architecture, debugger, error messages, etc. Therefore, for your first .NET Framework
migration project, start with a smaller application.

Other Technological Considerations

The technologies used by a legacy application heavily impact the decision to upgrade or rewrite it
for the .NET Framework. Although most technologies map readily to equivalents in the .NET
Framework, some do not. ActiveX DHTML projects and Active document are best left in VB 6.0.
Although Web Classes are not supported in VB .NET, the Visual Basic Upgrade Wizard will
upgrade most of the code to Web Forms. Migrating ASP applications to ASP.NET requires work
but there are many compatibilities that make it smooth. Code that makes operating-system level
calls, bypassing the higher-level libraries entirely, may have to be rewritten from scratch.



Application Upgrade Options
The strategy you use to perform the migration will be determined by the type of application and
the language that it uses. You must also consider the other resources used by the application as
mentioned earlier.

There are three primary options once you’ve decided to upgrade:

   Rewrite the application from scratch using part of the logic from your old version.

   Completely upgrade the application, leaving the old architecture intact.

   Upgrading or rewriting some portions code to the .NET Framework, leaving the remainder of
    the application as unmanaged and accessing it through the COM InterOp layer or managed
    extensions (C++) or by integrating both versions of the applications using XML Web Services.

The following discussion provides some insights into the advantages of each approach.



                                           Page 8 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




Rewriting

Rewriting your application from the ground up allows it to take maximum advantage of the .NET
Framework. Depending on the application’s nature, rewriting it from scratch may be the only way
to achieve the biggest potential performance boost available from the .NET Framework
implementation.

However, the cost of rewriting may be high depending on the complexity, quality of code, and size
of your application. Consider a complete rewrite only when an upgrade or partial upgrade is not
possible, performance is critical, or you want to take advantage of new features that need to be
designed from the ground up (such as, security). The cost of an upgrade might be close to the
cost of a rewrite if your application uses features that do not easily upgrade to the .NET
Framework or the code complexity is high, quality is low, and you do not want to work with your
legacy components through the COM InterOp layer.

Thus, a rewrite can offer the best performance and scalability, the cleanest design as a basis for
future upgrades, and can take full advantage of new features in .NET. However, it is also the
most labor-intensive, takes the longest to implement, and forfeits investment in old code

Complete or Partial Upgrade

Upgrading an entire application often seems the most attractive option, yet it can be difficult for
large, complex cases. Some portion of any sizable application will usually require rewriting from
scratch, or may be best left untouched and accessed through the COM InterOp layer if it is
component based. Upgrading those components or applications that benefit from the .NET
Framework’s scalability, maintainability, and robustness may be the most reasonable given
limited resources.

Thus, a complete upgrade can greatly improve performance and scalability, and afford the
chance to selectively re-architect portions to take advantage of new features in .NET. Preserving
the investment in existing code can entail less work and time than rewriting the entire application
from scratch, assuming code is worth preserving. However, for large applications, it may still be
labor intensive. There will inevitably be portions too difficult to upgrade that require a rewrite
either of necessity or to take full advantage of performance increases.

Therefore, a partial upgrade is the most likely scenario for large-scale applications. You may have
components that you do not want to change or cannot be easily upgraded to the managed world.
Although COM InterOp is slightly slower than managed code, performance is only a concern if an
interop component is accessed a frequently by one or more applications.

Thus, targeted partial upgrades offer improved performance and scalability with the largest bang
for the buck. Difficult-to-upgrade code or code that wouldn't benefit from an upgrade can remain
unmanaged. The performance boost will not be as great as an entirely managed solution, but the
biggest concern might be the difficulty in ongoing maintenance and deployment. Therefore it is
prudent to upgrade the easiest and most cost-effective portions first, and defer judgment on
remaining portions until gaining more experience with the architecture. Commonly, legacy
portions that were not worth upgrading are dropped from future versions or worth rewriting at
some later date.

After making modifications to get your application working in .NET, you can add value with new
features, such as instrumenting the application with Performance Counters or WMI data or
extending the application with XML Web services.



                                            Page 9 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




It is also easy to migrate part of an application and let this new application communicate with the
existing one. For any Win32 application, you can expose features of the application using XML
Web Services. The SOAP Toolkit facilitates adding this functionality to C/C++ program. Windows
Server Component Services uses the same core technology to allow Web Service interfaces to
be added to COM+ application without any programming. If your application is written in C++, you
can also migrate part of the application to Managed code using the Managed Extensions for C++.

The Microsoft Visual Basic .NET and Microsoft ASP.NET Upgrade Guide CD from MSDN offers
many more technical details and migration case studies.

For more information, see the following topics:

   Technologies for Integrating Multiple .NET Applications

   Microsoft .NET/COM Migration and Interoperability

   Visual Basic 6.0 Upgrade to Visual Basic .NET


Performing the Migration
Before an application is migrated, you should plan how the migration will happen. Next,
developers should perform the migration on development systems and test the new or
new/integrated applications before they put them back into production. You should also factor in
the time the upgrade will take.

Visual Basic 6 Applications

Initially, we recommend that you migrate applications that are easiest to update: components
(Dynamic Link Libraries (DLLs)), modules, classes, and standard syntax, and Forms. More
advanced upgrade projects are those containing ADO environments and data binding, ActiveX
controls or COM library references, two- and three-tier applications, and ASP front-ends with
Visual Basic business objects.

Projects including code that requires extensive manual modifications are considered advanced
migration projects. These include extensibility projects (add-ins), games that rely on VB 6.0
performance shortcuts, ActiveX DHTML applications that rely heavily on DHTML within a
browser, ActiveX documents, and legacy one-tier Microsoft Access database with DAO data
binding. Likewise, applications that intentionally go outside the bounds of VB 6.0 by altering the
message loops, sub-classing the forms, using advanced memory manipulation functions, and
other obscure features will require substantial effort to migrate to or rewrite in .NET.

Visual Basic .NET Upgrade Wizard
Visual Studio .NET includes a Visual Basic Upgrade Wizard that upgrades VB 6 code to VB
.NET, albeit with some limitations. Because of the differences between previous versions of VB
and Visual Basic .NET, most applications will require some rework for items that cannot be
automatically upgraded. The amount of rework required depends on many factors, including the
type of application, features, and your experience with upgrading.

The wizard will migrate most types of Visual Basic 6 applications such as Windows applications,
general code, and components (ActiveX components).



                                           Page 10 of 23
                                                             Microsoft® Windows® Server 2003 White Paper




The Upgrade Wizard upgrades Visual Basic 6.0 projects only. Visual Basic 5.0 projects must be
upgraded to Visual Basic 6.0 projects before upgrading to Visual Basic .NET.

The upgrade tool will typically upgrade about 95 percent of your application to Visual Basic .NET.
To determine beforehand what problems you might encounter while upgrading your application,
run the Upgrade Wizard once simply to create an upgrade report. Some issues might be easier to
tackle by first modifying your application in Visual Basic 6.0.

To use the Upgrade Wizard, open Visual Studio .NET and open your Visual Basic 6.0 application.
The wizard will start and walk you through the upgrade. As it moves along, it will create a new
directory for the upgraded application and display its status as it goes as shown below where
Step 5 of the wizard is processing.




Once the wizard completes, you will see an Upgrade report which is an HTML document in your
new solution. You will also find that the code has been commented with notices that point you to
concerns and even areas where you may need to make changes. The figure above was
generated as we migrated a simple ADO data layer that uses COM+. The upgrade required us to
make two changes:

   Add a reference to the COM+ type library to the new project.

   Change one property on a single line of code to handle the way the .NET Framework handles
    code versioning.




                                          Page 11 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




The Upgrade Wizard generates errors, warnings, and issues to alert you to both actual and
potential problems in your code. These errors messages are summarized in the upgrade report
that is generated, and each links to an online help topic explaining the nature of the problem and
the modifications you will need to make. Some of these issues need to be addressed before your
application can be compiled and run. The majority of the modifications you will require solve
syntactical and behavioral issues.

Listed below are some of the features that the Upgrade Wizard cannot automatically convert. The
Migration CD and VB .NET online help contain specific suggestions for converting these elements
manually or using COM InterOp to interface with the components currently used:

   OLE Container Control.

   Dynamic Data Exchange (DDE).

   Controls on Visual Basic forms can be bound to ADO, RDO, and DAO data sources. The
    Upgrade Wizard upgrades ADO data binding to the new ADO .NET data binding, but RDO
    and DAO data binding cannot be upgraded automatically and will be flagged as an error in
    the upgrade report.

   VB 5.0 projects and the VB 5.0 versions of many controls—including the Windows Common
    controls and the Data-Bound Grid control—are incompatible with Visual Basic .NET.

   ActiveX documents and DHTML applications can be left in VB 6.0; you can navigate between
    ActiveX documents, DHTML applications, and Web Forms.

   Property Pages are not supported in VB .NET. You should re-implement the properties on
    property pages as standard control properties.

   User Controls created with VB 6.0 can be used in VB .NET; however, user control projects
    cannot be upgraded in the current version of the Upgrade Wizard. However, the VB code in
    those controls may migrate easily as long as it uses features of the new Windows Forms
    architecture.

   Web Classes - the current version of the Upgrade Wizard cannot automatically upgrade Web
    Classes to Web Forms, but Web Classes can interoperate with VB .NET applications; you
    can navigate from a VB 6.0 Web Class to an ASP.NET application or vice-versa.

   Visual Basic Add-ins (third-party extensions) will need to be re-written in Visual Basic. NET.

   Games relying on specific performance characteristics of VB 6.0 may need to rewrite
    graphics code using GDI+.

   Graphics - VB 6.0 forms graphics methods, such as Line or Circle, cannot be automatically
    upgraded and must be re-implemented in Visual Basic .NET.

   Drag-and-Drop Functionality must re-implemented manually in VB .NET.

   The VB 6.0 Variant data type is converted to a VB .NET Object reference; this conversion
    can introduce some subtle differences in the application’s behavior.

   Some API calls - because of language changes, calls to particular APIs will need to be
    revised.

Some Visual Basic 6.0 ActiveX controls have equivalents in .NET, but some do not. Those for
which there are .NET Control equivalents also have property changes, even name changes, or



                                          Page 12 of 23
                                                              Microsoft® Windows® Server 2003 White Paper




may have been renamed compared to the ActiveX control. .NET also offers new controls not
previously available.

Unlike ActiveX controls, .NET controls are created from a hierarchy of other classes, at the top of
which is the Control class. If you create your own controls, it is easier to inherit from the
UserControl class, which contains commonly needed properties and events and draws
constituent controls for you. In addition to the standard controls, there are a whole group of new
controls in .NET.

The Upgrade Wizard does not detect runtime errors, as these errors are typically logic or late
bound errors. If an error occurs at runtime, use standard debugging techniques, and the .NET
debugger, to isolate the problem.

If you have an n-tier application, upgrade the client component first and get the new clients
working with the existing components. After the client is upgraded, upgrade the next component
in the dependency tree until you upgrade the topmost component in the component hierarchy. As
you upgrade each component, you can switch the components that depend on it so that they also
use the new upgraded version.

Upgrading the client and then the server components keeps the application working during the
different stages of the upgrade process. Upgrade in this order because using the component
object model (COM) from .NET is easier than accessing .NET from COM. In addition, you don't
have to change the Visual Basic 6.0 code; your Visual Basic .NET application simply calls what it
needs.

The most common runtime errors following conversion from VB 6.0 to VB .NET are due to:

   COM interoperability differences.

   Deterministic finalization issues with file handles, database connections, and resource
    handles.

   Event orders in forms.

For more information on VB 6 migration, see the following topics:

   The Visual Basic .NET Upgrade Guide

   Upgrading Visual Basic 6 to Visual Basic .NET

   Upgrading Your Visual Basic 6.0 Applications to Microsoft® Visual Basic® .NET

   Preparing Your Visual Basic 6.0 Applications for the Upgrade to Visual Basic .NET

   Preparing a Visual Basic 6.0 Application for Upgrading

ASP to ASP.NET

If you have a large ASP site, you will be amazed when you are finished with this process at the
amount of dead code, inefficiencies, and outright bugs you came across and fixed. Additionally,
you will be able to take advantage of the many powerful new features added to ASP.NET and the
.NET platform in general. If you follow the suggested migration approach, you can not only
quickly migrate, but also dramatically reduce the amount of code in your new application.




                                          Page 13 of 23
                                                                Microsoft® Windows® Server 2003 White Paper




Coexistence between ASP and ASP.NET Pages
ASP and ASP.NET pages and applications can co-exist on a server without adversely affecting
each other. ASP and ASP.NET use separate file extensions (.asp vs. .aspx) and separate
configuration models (metabase/registry vs. XML based configuration files), and separate
processing engines (IIS hands off ASP requests to asp.dll and ASP.NET requests to
aspnet_wp.exe).

A Web site or even a single web application within a site can contain both ASP.NET pages and
ASP pages, therefore not all existing ASP pages must be ported over to ASP.NET-compatible
pages. Coexistence is crucial when migrating large or rapidly changing sites to ASP.NET,
allowing you to use a phased-in approach.

Upgrading ASP Applications to ASP.NET
Porting existing ASP pages to ASP.NET pages requires more than simply renaming the file
extension from .asp to .aspx. Although this “rename” strategy can be a starting point and allows
you to find the compatibility problems quickly and fix them.

The majority of ASP applications use VBScript, and therefore, developers migrate ASP pages to
ASP.NET using Visual Basic.NET. VBScript is a subset of the VB language. This will make it
easy for VBScript developers to pick up VB.NET.

To upgrade a project from ASP to ASP.NET, start small. Find a few pages that have simple
HTML and ASP script, then one that has more complex code such as that accessing a database.
Then, follow the steps below:

1. Create a new ASP.NET project with Visual Studio.NET.
2. Change the ASP extensions from .asp to .aspx. Visual Studio.NET will automatically create a
   code behind page (.vb) for the new page but it will not migrate your code into it. The code will
   still be in the HTML for the page.
3. Set a start page for your project, preferably a simple ASP.NET page that provides a menu to
   the other pages.
4. Press F5 to compile and load the start page.

If there are any compile errors, they will show up in the Visual Studio .NET Tasklist. You can use
the TaskList to navigate to each error and fix it. Once the application compiles successfully, it will
display your start page in the browser.

When you navigate to a page that has a problem, the browser will show an error such as the one
shown below.




                                            Page 14 of 23
                                                                Microsoft® Windows® Server 2003 White Paper




This indicates that Option Explicit is not supported the way it was previously. Instead, it can be
set at the project level in Visual Studio .NET or in the page behind code. Once you see errors in
the browser, you can fix them. After a few pages, you will be familiar with the types of errors that
occur and fix them on the fly as you migrate the page.

The core methods and properties of ASP consist of a few intrinsic objects (Request, Response,
Server, etc.). With the exception of a few simple changes, these features will continue to function
correctly under ASP.NET.

Let’s walk through converting a simple ASP page to ASP.NET. The following ASP script is a
simple page that pulls data from a database table and displays it in a grid:
    <%@ Page enablesessionstate="false" CodeBehind="AuhorsRUs.aspx.vb"
    Language="vb" AutoEventWireup="false"
    Inherits="ASPWithDataToASPNET.AuhorsRUs" %>

    <%Option Explicit%>
    <HTML>
        <HEAD>
                <TITLE>Publisher</TITLE>
                <%response.buffer=true%>
        </HEAD>
        <body bgcolor="#ffffff">
                <H1 align="center">
                         <%
    dim sDSN
    dim sSQL
    dim oCon



                                           Page 15 of 23
                                                         Microsoft® Windows® Server 2003 White Paper




dim oRS
dim oEachField

sDSN="DSN=pubs;uid=sa;pwd=;"
sSQL="select * from publishers"

set oCon=server.createobject("adodb.connection")
oCon.open sDSN

set oRS=oCon.execute(sSQL)

If oRS.eof then
  response.write "No records matched<br>"
  response.write sSQL & "<br>So cannot make table..."
  response.end
end if
%>
                       <FONT color="#6600ff">Publisher Data</FONT></H1>
<%
response.write "<table border='1'><tr>" & vbcrlf
'Put Headings On The Table of Field Names
for each oEachField in oRS.fields
  response.write "<td><b>" & oEachField.name & "</B></TD>" & vbcrlf
next

do while not oRS.eof
    response.write "<tr>" & vbcrlf
    response.write "<td valign=top>"
    response.write oRS("Pub_id")
    response.write "</td>"

    response.write "<td valign=top>"
    response.write oRS("pub_name")
    response.write "</td>"

    response.write "<td valign=top>"
    response.write oRS("city")
    response.write "</td>"

    response.write "<td valign=top>"
    response.write oRS("state")
    response.write "</td>"

     response.write "<td valign=top>"
     response.write oRS("country")
     response.write "</td>"
     response.write "</tr>" & vbcrlf
  oRS.movenext
loop

response.write "</tr>" & vbcrlf
%>
             <H1></H1>



                                        Page 16 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




        </body>
    </HTML>
Now, lets see what this page looks like in ASP.NET with no changes except those required to get
it working.

One of the most frequent things you must change is to add parentheses around all arguments to
method calls. This is a welcome change as it simplifies the reading and creation of code. The
error message you will see in the browser from this is:

BC30800: Method arguments must be enclosed in parentheses.

Now here is a tip: If you paste code into the Visual Studio .NET code editor, it will add them for
you! So, copy your VBScript to the clipboard, paste it into the Code Editor (just use the code
behind page) and viola, you should see () around all your calls to the method of a subroutine.
Then you can copy the code back to the clipboard and past it back into the HTML.

To convert the ASP script above into ASP.NET code, the new page looks like this:
    <%@ Page aspcompat=true enablesessionstate="false"
    CodeBehind="AuhorsRUs.aspx.vb"
    Language="vb" AutoEventWireup="false"
    Inherits="ASPWithDataToASPNET.AuhorsRUs" %>
    <HTML>
        <HEAD>
                 <TITLE>Publishers</TITLE>
                 <%response.buffer=true%>
        </HEAD>
        <body bgcolor="#ffffff">
                 <H1 align="center">
                          <%
    dim sDSN
    dim sSQL
    dim oCon
    dim oRS
    dim oEachField

    sDSN="DSN=pubs;uid=sa;pwd=;"
    sSQL="select * from publishers"

    oCon=server.createobject("adodb.connection")

    oCon.open( sDSN)
    oRS=oCon.execute(sSQL)

     If oRS.eof Then
           Response.Write("No records matched<br>")
           Response.Write(sSQL & "<br>So cannot make table...")
           Response.End()
         End If
    %>
                         <FONT color="#6600ff">Publisher Data</FONT></H1>
    <%




                                           Page 17 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




         Response.Write("<table border='1'><tr>" & vbCrLf)
         'Put Headings On The Table of Field Names
         For Each oEachField In oRS.fields
           Response.Write("<td><b>" & oEachField.name & "</B></TD>" & vbCrLf)
         Next

         Do While Not oRS.eof
          Response.Write("<tr>" & vbCrLf)
          Response.Write("<td valign=top>")
          Response.Write(oRS.Fields("Pub_id").value)
          Response.Write("</td>")

           Response.Write("<td valign=top>")
           Response.Write(oRS.Fields("pub_name").value)
           Response.Write("</td>")

           Response.Write("<td valign=top>")
           Response.Write(oRS.Fields("city").value)
           Response.Write("</td>")

           Response.Write("<td valign=top>")
           Response.Write(oRS.Fields("state").value)
           Response.Write("</td>")

           Response.Write("<td valign=top>")
           Response.Write(oRS.Fields("country").value)
           Response.Write("</td>")
           Response.Write("</tr>" & vbCrLf)
           oRS.movenext()
         Loop

         Response.Write("</tr>" & vbCrLf)
    %>
                  <H1></H1>
        </body>
    </HTML>
The things that were done to make this page work are:

   Delete the Option Explicit statement.

   Delete the Set statements.

   Add () around calls to methods.

   Change the syntax to access the recordsets data to: oRS.Fields("state").value. This change
    is required because of the requirement to explicitly reference properties unless the property is
    indexed.

   Add the aspcompat=true attribute to the Page directive to allow Apartment Threaded
    Components to run.

Instead of leaving all the script code mixed with the HTML, why not begin to move things into the
code behind structure that ASP provides and use some of its widgets to minimize your coding?




                                             Page 18 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




Let’s walk through the last example and move it into this new structure. When we are finished, we
will look at the advantages.

The main changes using this approach are to

    1) Move all of the script code into the Page_Load of the code behind file. You can access
       the code behind file by pressing F7 or selecting View Code from the Design editors’
       context menu.

    2) Drag a DataGrid control from the Web Forms section of the Toolbox and drop it on the
       Web Form.

    3) Drag a Label control and add it to the form.

    4) Modify the code to work with the new controls.

Now, modify the code. Switch to the code for the page. Now, strong type the variables:
    Dim sDSN As String
    Dim sSQL As String
    Dim oCon As ADODB.Connection
    Dim oRS As ADODB.Recordset
    Dim oEachField

Next, change the CreateObject statements to use the New operator like this:
    oCon = New ADODB.Connection()

    oRS = New ADODB.Recordset()

Change the code in the If statement to place the text in Label1 if there is a problem:
    If oRS.EOF Then
         Label1.Text = "No records matched" & vbCrLf
         Label1.Text &= sSQL & "<br>So cannot make table..."
         Exit Sub
    End If



Add the following line to bind the DataSource property of DataGrid1 to the output of
RecordsetToDataTable (we will get to this function in a moment):
    DataGrid1.DataSource = RecordsetToDataTable(oRS, "Publishers")
    Page.DataBind()

Close the Recordset:
    oRS.Close()
The entire code looks like this:
    Dim sDSN As String
    Dim sSQL As String
    Dim oCon As ADODB.Connection



                                            Page 19 of 23
                                                                Microsoft® Windows® Server 2003 White Paper




    Dim oRS As ADODB.Recordset
    Dim oEachField

    sDSN = "DSN=pubs;uid=sa;pwd=;"
    sSQL = "select * from publishers"

    oCon = New ADODB.Connection()

    oRS = New ADODB.Recordset()

    oCon.Open(sDSN)
    oRS = oCon.Execute(sSQL)

    If oRS.EOF Then
         Label1.Text = "No records matched" & vbCrLf
         Label1.Text &= sSQL & "<br>So cannot make table..."
         Exit Sub
    End If

    DataGrid1.DataSource = RecordsetToDataTable(oRS, "Publishers")
    Page.DataBind()

    oRS.Close()



Notice how little code is required in the page now compared to where we started?

To finish the migration, add a new Module to the project and name it ADOConvertor.vb. Add the
following function to it:
    Function RecordsetToDataTable(ByVal adoRS As ADODB.Recordset, _
        ByVal strTable As [String]) _
        As DataTable

        adoRS.MoveFirst()
        Dim dt As New DataTable(strTable)

        Dim i As Integer
        For i = 0 To adoRS.Fields.Count - 1
                  Dim strColName As [String] = adoRS.Fields(i).Name
                  Dim t As Type = adoRS.Fields(i).Value.GetType()
                  dt.Columns.Add(strColName, t)
        Next i

        While Not adoRS.EOF
                Dim dr As DataRow = dt.NewRow()
                For i = 0 To adoRS.Fields.Count - 1
                          dr(i) = adoRS.Fields(i).Value
                Next i
                dt.Rows.Add(dr)
                adoRS.MoveNext()
        End While




                                             Page 20 of 23
                                                                 Microsoft® Windows® Server 2003 White Paper




        Return dt
    End Function
The RecordsetToDataTable function takes as parameters an ADO Recordset and the name for
an ADO.NET DataTable and returns the DataTable populated with data from the recordset.
Placing the function in a module allows you to place this module in a project, call this function
from any page in the project, and dramatically reduce the amount of code in each page.

This approach also allows you to easily migrate to ADO.NET fully in the future by changing only a
small amount of code.

Application Configuration Changes
In ASP, all Web application configuration information is stored in the system registry and the IIS
Metabase, which required the Internet Services Manager snap-in to view or modify settings.
ASP.NET uses human-readable XML files instead that, with the exception of some security
settings, ignore settings configured via the IIS administration tools.

Each ASP.NET application has its own web.config file, which lives in its main application
directory, and configures the behavior and security of the application. The most important settings
in the web.config file are:

   <appSettings> - Configures custom application settings.

   <authentication> - Configures ASP .NET authentication support.

   <pages> - Identifies page-specific configuration settings.

   <processModel> - Configures the ASP .NET process model settings on IIS systems.

   <sessionState> - Specifies session state options.

The .NET Base Class Libraries include classes that give programmatic access to these same
settings.

State Management

If your application uses the ASP Session or Application intrinsic object to store state information,
you can continue to use these in ASP.NET. ASP.NET, however, adds options to support state
management across a Web farm. You can configure session state management by setting the
mode attribute in the <sessionState> section of your web.config file to Inproc, StateServer,
SqlServer, or Off.

   Inproc - Session state is stored locally on a single server (ASP style).

   StateServer - Session state is stored in a state service process located remotely or potentially
    locally.

   SqlServer - Session state is stored in a SQL Server database.

   Off - Session state is disabled.

In most cases, Inproc will give the best performance, followed by StateServer and then
SqlServer. Perform tests with your application to ensure the option you choose meets your
performance goals. If you store references to legacy COM components in the Session or




                                           Page 21 of 23
                                                               Microsoft® Windows® Server 2003 White Paper




Application object, you cannot use the StateServer or SqlServer modes, and must instead use
Inproc because COM components are not self-serializable.

Although an application can contain both ASP and ASP.NET pages, they cannot share state
variables stored in the intrinsic Session or Application objects. You either need to duplicate the
state information in both systems or come up with a custom solution until your application is fully
migrated.

"Converting ASP to ASP .NET" provides information about running ASP and ASP.NET on the
same server and porting ASP applications to ASP .NET.

For more information, see the following topics:

   Migrating ASP Pages to ASP.NET

   ADO Rocks and Rolls in .NET Applications

   Converting ASP to ASP.NET

   How to Upgrade ASP Pages to ASP.NET Pages That Use JScript .NET

Migrating C++ Applications to Managed C++ or C#

Managed C++ is a superset of C++ with some added keywords and features required to support
.NET. Managed C++ allows you to develop managed objects in C++, with the attendant
performance benefits, but run them under the CLR. Although you can mix managed and
unmanaged code, unmanaged (native) C++ code generally performs faster than its managed
equivalent. That is, although there is a small performance overhead incurred by managed code,
the overall performance of .NET Framework applications often improves despite it. However, if an
application does not take advantage of areas in which .NET offers performance improvements,
such as ADO.NET over the older ADO, application performance might decrease marginally. Even
then, the small performance degradation may be worth improvements in other areas, such as
increased reliability.

To convert C++ code to Managed C++, add the mscorlib.dll and the System namespace at the
beginning of your code. Also add the Lang namespace surrounding all routines, including static
routines, public routines, and class methods, with the exception of main(), such as:
    #using <mscorlib.dll>
    using namespace System;

    nameSpace Lang
    {
      __gc __interface ISomeInteface {
        // your code goes here
      }
    }
Note the two new keywords __gc and __interface; __gc tells the CLR to perform garbage
collection on unused references, and __interface declares a .NET interface, which is roughly
equivalent to a C++ abstract base class.




                                           Page 22 of 23
                                                                  Microsoft® Windows® Server 2003 White Paper




Experienced C++ and Java developers will find C# very familiar and easy to pick up. The C#
example is similar to that of Managed C++, except we can omit things that are built into the C#
language, such as __gc and __interface, thus leaving
    using System;

    nameSpace Lang
    {
      interface ISomeInteface {
        // your code goes here
      }
    }
Unlike Managed C++, but like VB.NET, the C# compiler requires you to explicitly declare whether
a method is abstract, public, private, etc., by adding keywords such as:
    public abstract void DoSomething();


Conclusion
The .NET platform makes it easy and beneficial to migrate traditional Win32 applications to .NET.
The architecture also drastically reduces the amount of code in your applications, even ASP
applications you migrate to ASP.NET as shown in the earlier example. In one fell swoop you can
migrate applications to the .NET Framework and achieve many benefits:

   Performance enhancements.

   Wide choice of languages, all interoperable.

   Web-based interoperability standards (XML).

   Simplified plumbing and housekeeping with greatly enhanced functionality.

   Sophisticated features (scalability, reliability, deployment) for “free”.


Related Links
   What's New in Application Services

   Application Server Technologies

   Moving Windows NT 4 and Windows 2000 Applications to Windows Server 2003

   Migrating UNIX and Other Applications to .NET

   Managing Multiple Versions of the .NET Framework

   Legacy Application Integration Inside the Firewall




                                            Page 23 of 23

				
DOCUMENT INFO
Description: Migrating Win32 Applications to Windows Server 2003