Migrating
Existing VC/VB/ASP Applications to .NET
Host: Narayana Rao Surapaneni – Microsoft MVP | Technology
Expert, .NET & Web Services Technology Group, Patni
July
19, 2002
KunalS_MS: Good Afternoon to all once again and thank you for joining
the first Expert Chat Session of eXPerienceDotNet.
NarayanaRao_MVP: Hello, good afternoon everyone.
KunalS_MS: Sorry for this delay on our part and we shall hope to make
it upto you soon
KunalS_MS: Today's expert host is Narayana Rao Surapaneni. Narayana
is a technology expert with the.NET & Web Services Technology Group
at Patni. Besides that, he is a Microsoft MVP for his exemplary contributions
to the community.
KunalS_MS: He has authored several books and whitepapers and is well
known in the academic circles.
KunalS_MS: Narayana shall be today discussing with us methodologies
for Migrating Existing VC/VB/ASP Applications to .NET.
KunalS_MS: In the first half, Narayana will be sharing his best practices;
following which he shall be taking up queries from you.
KunalS_MS: Narayana comes with a vast experience of working on both
Microsoft and non-Microsoft platforms
KunalS_MS: and is indeed one of the most credible experts to speak
on a migration path
KunalS_MS: Over to you Narayana
NarayanaRao_MVP: Hey Kunal let me take this opportunity
to welcome all and I shall start with the need for migration
NarayanaRao_MVP: We, at Patni, have developed a migration
approach for migrating legacy applications (defined as an application
developed in Visual Basic (VB), Visual C++, ASP and using COM technology)
into Microsoft .NET environment. In this session, I'll be discussing
NarayanaRao_MVP: some of the points regarding the migration
process and some general guidelines to be followed during migration.
NarayanaRao_MVP: Application development is generally
carried out in multi-tiered approach; for example, a web-based application
will have three tiers, i.e., presentation tier, business tier and
database tier.
NarayanaRao_MVP: The presentation tier comprises of HTML
pages with ASP scripting, the business logic is generally encapsulated
in COM components. The database tier normally represents a data store
like MS SQL Server.
NarayanaRao_MVP: There can be several approaches for migrating
such applications. In order to migrate the application, we can choose
to migrate one tier at a time to migrate the entire application to
.NET. This approach is known as the tier-based approach for migration.
NarayanaRao_MVP: In this approach, the presentation layer
is migrated to .NET. In this case the front-end interacts with the
COM components through an interoperability layer. The .NET Framework
generates a Runtime Callable Wrapper to interoperate between the migrated
NarayanaRao_MVP: front-end and the legacy COM component.
NarayanaRao_MVP: After migrating the presentation layer
to .NET, the code for the COM components can be either migrated to
a .NET component. Alternatively, the COM component can be exposed
as a Web Service.
NarayanaRao_MVP: Another approach can be to isolate some
functionality from the application and migrate the functionality across
all tiers. This is known as the functionality-based approach to migration.
The steps described above will be followed for each functionality.
NarayanaRao_MVP: The above mentioned approaches for migration
are general in nature and can be applied to any application. We will
now discuss specific methodologies for Visual Basic to Visual Basic.NET,
VC++ to VC++.NET and ASP to ASP.NET.
NarayanaRao_MVP: Project selection guidelines Selecting
an application for migration can be done based on:
NarayanaRao_MVP: 1. Application Requirements for Scalability
and Performance
NarayanaRao_MVP: 2. Application Architecture
NarayanaRao_MVP: 3. Nature of Code
NarayanaRao_MVP: Now let's considering migration VB applications
to VB.NET
NarayanaRao_MVP: Visual Basic language has undergone tremendous
changes under the .NET Framework. Visual Basic .NET is a complete
object-oriented language with features like structured exception handling,
multithreading, etc, which were not previously present in VB
NarayanaRao_MVP: In order to assist developers to migrate
their VB applications to .NET, Microsoft has provided the Upgrade
Wizard as a part of the Visual Studio .NET. Whenever a Visual Basic
6.0 project is opened in Visual Studio .NET, the Upgrade Wizard is
invoked.
NarayanaRao_MVP: However, there are many features and
syntaxes in the VB language that are not supported and do not have
a direct mapping in VB.NET. As a result, the Upgrade Wizard does not
convert the application completely to .NET.
NarayanaRao_MVP: Though the Microsoft has provided the
upgrade wizards with .Net Framework to upgrade and migrate the existing
applications, but these wizards does not fulfill the enterprise application
needs. These wizards simply help you in compiling and run your apps
NarayanaRao_MVP: If you want to migrate a given business
application with minimal changes and at the same time exploit the
features provided by .NET, we need to work out the strategy for the
migration and calculate the cost of migration in terms of effort and
the time
NarayanaRao_MVP: We at Patni tried to fill this vacuum
by putting forward the migration methodology which will reduce the
cost estimation of migration and at the same time provides the direction
in which one should proceed a path which can lead the managers to
achieve
NarayanaRao_MVP: the same
NarayanaRao_MVP: The commonly arising issues are code
related to DDE, OLE, etc. For all such problems links are provided
in the upgrade report pointing to MSDN, which provide information
on why the code was not upgraded along with information on what the
developer can do
KunalS_MS: Welcome back Narayana
NarayanaRao_MVP: The path for migrating a Visual Basic
6.0 application to Visual Basic .NET is as follows:
NarayanaRao_MVP: Perform an assessment based on project
selection guidelines
NarayanaRao_MVP: The assessment is required to know the
complexity that will be involved in migrating the application and
whether migration will be worth the efforts involved.
NarayanaRao_MVP: This assessment phase gives an insight
into understanding the complexity of application under considerations.
NarayanaRao_MVP: In assessment phase, application is classified
as simple, medium or complex depending on the complexity involved
in the migration process.
NarayanaRao_MVP: what's important while migrating applications
is to define pre-migration recommendation and post-migration recommendations
NarayanaRao_MVP: Pre-migration recommendations help us
in modifying the existing applications before actually taking off
the migration with minimal time and cost factors
NarayanaRao_MVP: They also help in designing current VB
6.0 applications feature ready for migrating them to .NET when such
a needs arises
NarayanaRao_MVP: The pre migration phase ensures smooth
migration to Visual Basic .NET and minimizes the number of changes
that needs to be done, when the application has been upgraded to Visual
Basic .NET.
NarayanaRao_MVP: 3. With the help of upgrade wizard, upgrade
Visual Basic 6.0 application to Visual Basic .NET
NarayanaRao_MVP: During the upgrade process, upgrade wizard
doesn't solve all the issues. These issues can cause a design error
or compiler error or runtime warnings. The methodology attempts to
overcome this limitation by giving proper workarounds
NarayanaRao_MVP: Let's now move on to ASP.NET
NarayanaRao_MVP: ASP applications can be developed using
any scripting language like VBScript, JScript, etc. Also, there is
no specific technique for coding since scripts can be embedded in
HTML code and the page is rendered accordingly.
NarayanaRao_MVP: While migrating ASP applications to ASP.NET,
it is essential that certain coding standards be followed. More so,
since there is no upgrade wizard associated with ASP applications
to help developers.
NarayanaRao_MVP: The coding standards include use of parentheses
while making method calls and declaring variables using Dim, etc.
These are included under the pre-migration changes.
NarayanaRao_MVP: These changes can also be taken as best
practices to be followed for any new ASP application being developed.
NarayanaRao_MVP: Pre-Migration strategy comprises of making
changes in the code of the existing ASP application so as to make
it compliant with the .NET Framework.
NarayanaRao_MVP: This includes declaring variables using
the DIM keyword, using parentheses for method calls and avoiding inline
code and render functions.
NarayanaRao_MVP: The actual migration can be carried out
by breaking up the application according to functionality. The categorization
of functionality includes
NarayanaRao_MVP: User Interface: This comprises of HTML
controls, which are migrated to server controls provided by the .NET
Framework
NarayanaRao_MVP: similar classifications can be made for
Data Access, COM components, Session management, etc.
NarayanaRao_MVP: lets move to the VC++.Net now
NarayanaRao_MVP: When you say migration in context to
VC++, its altogether different game as compared VB, ASP ...
NarayanaRao_MVP: Migration Methodology for Visual C++
.NET Methodology for migrating VC++ applications to VC++ .NET takes
following steps: a.Migrating an existing C++ class b.Interfacing with
database c.Web services d.Interoperability with unmanaged code
NarayanaRao_MVP: Hey Kunal Let's get started with Q &
A; In case participants have any queiries relating to migration methodologies
in detail I request them to post questions in forums and I shall answer
them.
Moderator: (Kumar) You mentioned about migration of COM components
by exposing them as webservices. The state management will get affected,
since WebServices are stateless in nature, while a COM component maybe
stateful. So, what strategy would be applicable here?
Moderator: (Kumar) Is it migrate only stateless components to webservices?
NarayanaRao_MVP: There are many ways of maintaining session
in web services too. Say in case of VC++.NET, ATL provides classes
to do the same and you may have to modify your code to some extent.
NarayanaRao_MVP: There are other workarounds like using
SQL Server to maintain the session state in the database but might
need a good expertise
Moderator: (Biswajit) We have an ecommerce application in ASP, COM,
COM+ and ADO. What will be the performance if we use COM interop with
ASP.NET?
NarayanaRao_MVP: It depends on the parameters relating
to (Critical to Performance) like number of current users and load
on web server etc. In case earlier COM components are using threading
models like single threaded and apartment threaded model, we suggest
using
NarayanaRao_MVP: much better threading models available
in win 2K etc as they dramatically help in increasing the performance.
NarayanaRao_MVP: Please also have a look a the calls made
to the COM...
NarayanaRao_MVP: Yet times, depending on the number of
calls made to COM and specially when performance is critical to your
apps consider migrating COM to .NET rather than using interop
Moderator: (Biswajit) But with same COM components using interop how
with the new threading model help?
NarayanaRao_MVP: If the current COM meets current needs
of your existing apps please consider using the same component...
Moderator: (Kumar) Yes, you are right. But that state management is
dependent upon the ASP.NET runtime. I can lose state anytime, whether
application state or session state. Does that mean webservices are
equally good alternatives for migration, when compared to writing
that component as a .NET component?
NarayanaRao_MVP: Are u referring to COM state or ASP.NET
state?
Moderator: (Kumar) I am referring to the state maintained by a component.
Moderator: (Kumar) ...in the context of stateful and stateless components,
just like we have stateless component design for component designed
to take advantages of pooling under MTS.
NarayanaRao_MVP: in that case we suggest you to migrate
the COM to .NET Component rather than web service.
Moderator: (Dhananjay) What are the advantages of migrating from VC++
to VC++ .NET?
NarayanaRao_MVP: AS such you can compile your VC++ Code
in VC++.NET ...but in case u wont to exploit the features ...you may
want t o migrate ...and some time it may depend upon the infaceiing
with the rest of the system
Moderator: (raj) In ASP application we use CDONTS for sending mails.
While migrating to ASP.NET, how do we take care of that?
NarayanaRao_MVP: We suggest writing your own POP 3 mail
Component rather using CDONTS, this actually falls under one of our
pre-migration recommendations
Moderator: (Kumar) While interacting with unmanaged code, what is
better to use from the perspective of migration? Managed extensions
for C++ or PInvoke?
NarayanaRao_MVP: If the calls to the unmanaged code are
quite high then in that case opt for the pinvoke........
Moderator: (Biswajit) Migrating from COM to .NET option is always
there, with interop and asp.net how will it perform?
NarayanaRao_MVP: In Case the application does not demand
the high scalability, in general we found not much performance difference.
NarayanaRao_MVP: This we tested while using performance
counters...custom written ones by us
Moderator: (Kumar) So, does that mean PInvoke is better than managed
extensions? If so, why?
Moderator: (Kumar) Infact, when using PInvoke, translation of parameter
data types is rather cryptic. For instance, a Win32 HANDLE, which
is a pointer, is represented as an "int"!
Moderator: (Kumar) On the other hand, doing the same using ME for
C++ will follow the natural way of referring to it as a pointer. Finally,
both use the same interoperability layer. Then what rationale should
be used to prefer one over the other, assuming all required skill
set is available?
NarayanaRao_MVP: Again it depends upon the application
requirement ...but interop cost is always there with managed extension
...idea of using PInvoke is to minimize that
NarayanaRao_MVP: we need to analyze the no. of interop
call and also should take into consideration performance requirements
of your app and of course data marshalling also plays its role
NarayanaRao_MVP: most of the time we can conclude on case
to case basis rather than making it more generic
Moderator: (gary_no_1) Does migrating a Visual FoxPro App to .NET
imply a complete rewrite?
NarayanaRao_MVP: At the moment we have explored in depth
the migration strategies for VB, VC, ASP, JScript, JUMP, COBOL etc
hence really can't make any comment on this.
KunalS_MS: This shall be out last question of the day
Moderator: (Kumar) What should be the migration strategy for data
tier access, when moving from ADO to ADO.NET? Considering, except
the name, there's nothing much common between them.
NarayanaRao_MVP: Many ASP applications commonly make use
of ADO for handling database activity. Under the .NET Framework, ADO.NET
takes care of all the database activities.
NarayanaRao_MVP: But, we can continue using ADO in ASP.NET
by adding a reference to the ActiveX Data Object Type Library in the
ASP.NET Web application. This way the developer can retain existing
code using ADO.
NarayanaRao_MVP: It is however not recommended that you
import and use ADO in .NET applications, but if you must, you should
have good reasons for doing so.
NarayanaRao_MVP: In situations where a lot of working
ADO code already exists in an application and a lot has been invested
in business objects that use ADO to read and write, ADO should not
be replaced with ADO.NET.
NarayanaRao_MVP: If you have a lot of ADO code that you
want to preserve, you must first determine where that code is located,
whether it is in ASP pages buried in plain-code blocks or in COM business
objects that return recordsets to the ASP presentation builder layer.
NarayanaRao_MVP: For performance and maintenance reasons,
placing plain ADO code in ASP pages is a bad programming practice.
In such cases, the ADO code is nearly legacy code. Such code can be
adapted to work in .NET but some performance and coding issues can
crop up.
NarayanaRao_MVP: The code changes in using ADO with ASP.NET
will be mainly due to difference in the way objects are created in
ASP and ASP.NET. In ASP, we use late-binding to create objects while
ASP.NET supports early binding.
NarayanaRao_MVP: In case of a number of applications sharing
the same database, performance is a major issue. Also, transmitting
data across a number of applications is a problem due to lack of standards
in the manner in which data can be sent and received.
NarayanaRao_MVP: This is a one of scenario for migrating
ADO to ADO.NET
Moderator: (Kumar) That would be calling for a performance hit, courtesy
interoperability. Assuming one is ready to shift completely to ADO.NET,
what migration consideration should be borne in mind?
NarayanaRao_MVP: I suggest complete re-write. However,
there should be need to migration apps rather just migrating it for
the purpose since it supports. Unless your application demands high
performance requirements ideally in most scenarios we can avoid
NarayanaRao_MVP: migrating to ado.net
NarayanaRao_MVP: the whole idea of interop is to save
the existing investments that the corporates have made!!!
NarayanaRao_MVP: migration, interoperating and moving
to .NET are three different terms and these options needs to be carefully
chosen depending on the needs to meet the business and application
requirements.
KunalS_MS: We shall draw today's session to a close here
KunalS_MS: Thank you very much Narayana
KunalS_MS: for taking out time to share with us all such excellent
tips & tricks
NarayanaRao_MVP: Thanks a lot and looking forward to meeting
you all again.
KunalS_MS: I would like to thank all of you also for taking time out
and joining us in today's session
KunalS_MS: If we have not been able to answer any of your queries,
please do post them in the discussion forums and Narayana shall adequately
respond to them.
NarayanaRao_MVP: For all those question which need more
explanation please post them in the forums and I shall attend to them
KunalS_MS: Also, please do take some time out share your valuable
feedback and suggestions at - http://www.microsoft.com/india/communitysatsurvey
KunalS_MS: Once again, thank you all for joining in.
