Transcript Microsoft Web Development Roadmap

ISV Community Day
Best Practice
Per Ahlberg
Developer Evangelist
Developer & Platform Evangelism
Microsoft Sweden
Agenda




General Best Practices
COM Components best practice
Data layer best practice
ASP to ASP.NET Best Practices
General Migration Strategy




Identify the parts of the application that you have to
migrate
Plan very carefully and try to have minimal impact on the
existing application during the migration
In a multi-tier scenario, take the horizontal or vertical
approach

Horizontal

Vertical
–
migrate the whole tier
(middle/presentation) at the same
time
– migrate some pages, some
components, at the same time
Decide if you want to reuse existing COM components
Migration Best Practices

Data access related


COM related



If you have a data access tier, move it into .NET
Always use early binding
Explicitly free resources from code
Project management related


Keep two code trees while migrating, and make sure to update
both of them while adding changes to the existing Web site
First try to modify the existing code as it is

After you complete this, try to modify the application to use the
advantages provided by .NET
Migration Best Practices

Testing related



Update existing links to your Web site/pages because
the file name extension is now .aspx
Use a link checker to check any broken links, images,
paths, and so on
Test very well
Migrating Applications that Use COM
Components

COM related changes:





ASP.NET uses MTA instead of STA
Pages with STA components may or may not perform well
Early binding is preferred in ASP.NET
Cannot use ASPCOMPAT with WebServices
COM Interop



Can use all your former COM components
Use ASPCOMPAT keyword if you plan to use existing STA
components in ASP.NET
Use ASPCOMPAT only when using STA objects or when your
COM objects access ASP intrinsic objects
Migration Best Practices

Language related







Strongly type all the variables
If possible, convert all the On Error statements to try catch
blocks
Remember that they may not be as easy as they look
Use call keyword for function calls and use parenthesis for
function and subroutine calls
Identify default properties and replace them appropriately
Always use Option Explicit
Remove Microsoft.VisualBasic namespace
ADO  ADO.NET
ADO evolves into ADO.NET
DataReader
RecordSet
DataAdapter
DataSet
Command
Command
Connection
Connection
Migrating Applications that Use
Databases

Data access changes





ADO (through Interop) can be used, but Microsoft
does not recommend it
ADO and ADO.NET are quite different
ADO.NET is not exactly backward compatible
Three main objects in ADO.NET: DataSet,
DataReader, and DataAdapter
Built-in designer support for ADO.NET objects in
Visual Studio .NET
Migrating Applications that Use
Databases

Strategies





Rewrite ADO code in ADO.NET instead of migrating
Keep ADO code as a short term approach
If you use ADO code in ASP pages, use Primary Interop
Assembly for ADO on both the developer box and the server
If you need read-only data, use a DataReader
High level strategies:


Replace VB6 components directly by VB.NET components,
horizontally or vertically
Let ASP.NET call Web Services that encapsulate VB6 business
components, then migrate these as needed to .Net
Replacing VB6 components directly


Your .NET code can talk directly to VB6 COM
code, but...
If your VB6 business components require
passing variants, write strongly-typed
“inbetween” .Net components (adapters)


ASP.NET talks to the inbetween components
The inbetween components talk to the existing VB6
components and perform data conversion to strong
types
Replacing VB6 components directly

VB6.MyWeakComponent:
Public Function UpdatedData(Name As String, Age As
Variant, MyDataArray As Variant) As Variant
VBNet.MyStrongComponent:

Public Function UpdatedData(Name As String, Age As
Integer, MyDataArray As Array Of Single) As Double

In version 1, VBNet.MyStrongComponent calls
VB6.MyWeakComponent and performs type conversion as
needed
Replacing VB6 components directly
Before
.NET
VB6 comp Business
logic
After
.NET
VB.NET
comp
Adapter
logic
VB6 comp Business
logic
Replacing VB6 components directly


By building these adapter components, .NET code can be
fully typed as needed and the UI can be completely
replaced
As a next step, you can change the VB.NET Business
components to replace the VB6 business components

 You have now replaced your Business logic layer
Migrating Applications that Use COM
Components

COM related changes:





.NET uses MTA instead of STA
ASP.NET Pages with STA components
may or may not perform well
Early binding is preferred in .NET
Cannot use ASPCOMPAT with WebServices
COM Interop



Can use all your former COM components
Use ASPCOMPAT keyword if you plan to use existing STA
components in ASP.NET
Use ASPCOMPAT only when using STA objects or when your
COM objects access ASP intrinsic objects
Replacing components layer by layer

If your original VB6 code returned ADO
Recordsets, it is best to make the VB.NET
versions return ADO.NET DataSets instead:




Convert ADO Recordsets to ADO.NET DataSets as
needed in the Business layer
ASP.NET then works only with ADO.NET
Many ASP.NET Web Controls work with DataSets
ADO.NET DataSets can be marshalled efficiently
even across physical tiers
Replacing components layer by layer



Later, migrate the Data layer and make it return
ADO.NET DataSets instead of ADO Recordsets
Remove the RecordsetDataSet conversion code from
the Business components
For components you can’t migrate, stick to COM Interop
Replacing components layer by layer

What about transactional integrity and security
context?



In VB6 under Windows NT: MTS
In VB6 under Windows 2000: COM+
In .NET: COM+
Replacing components layer by layer

Derive your façade components from the
ServicedComponent base class to use COM+
transactions and security


Use attributes to control configuration


Interestingly, the components that a ServicedComponent calls
don’t need to be serviced – they use the caller’s context!
Best to put them in the AssemblyInfo.vb file
Register your façade’s assembly in the GAC
Wrapping VB6 components
by .NET Web Services




Alternatively, start by having your ASP.NET
pages consume .NET Web Services that wrap
the VB6 components
This allows for easy separation in physical tiers
(dedicated application servers) as well as logical
tiers
A better option to separate in physical tiers is to
use .Net Remoting
If you need transactional integrity across
physical tiers, use Serviced Components
Wrapping VB6 components
by .NET Web Services
Before
.NET
After
.NET
Physical boundary
VB6 comp Business
logic
ASP.NET
Web
Service
Adapter
logic
VB6 comp Business
logic
Wrapping VB6 components
by .NET Web Services
Before
.NET
After
.NET
Physical boundary
VB6 comp Business
logic
ASP.NET
Web
Service
VB.NET
comp
Wrapper
logic
Business
logic
Wrapping VB6 components
by .NET Web Services



Web Services use open standards
You can open your business logic to other applications as
well, over the Internet, if you want
But be careful: Web Services can be transactional, but only
as the transactional root

You can’t combine more than 1 Web Service into a transaction
Replacing VB6 components indirectly
with Remoting
Before
ASP
After
.NET
Physical boundary
VB6 comp Business
logic
VB.NET
comp
Adapter
logic
VB6 comp Business
logic
Replacing VB6 components
indirectly with Remoting


Remoting is “.Net DCOM”
Better performance than with Web Services



We measured TCP binary remoting to provide 200%-300% the
speed of web services with SOAP
Calling a component through remoting does not
maintain transactional integrity and security context,
however
Remoting only works from .Net to .Net
COM Best Practice

Use Primary Interop Assemblies





Visual Studio ships with PIAs


Produced by COM API owner
May be modified for correctness or managed client friendliness
Recognized by Visual Studio.NET
Ensure consistent identity for Interop types
C:\Program Files\Microsoft.NET\Primary Interop Assemblies
Office 2003 PIAs also available

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/office.
asp
Typed DataSets






Contain structured data:
ShoppingCart, UserProfile, Catalog
Are classes that inherit from DataSet
Inherit all DataSet’s standard functionalities
Automatically copyable, mergable, serializable,
...
Can be autogenerated by the .NET framework’s
xsd.exe tool
Typed DataSets

Add properties specific to the structured data:

IntelliSense!
Untyped
ds.Tables(“Customers”).Rows(0).Columns(“Name”) _
= “Steve Ballmer”
Typed
ds.Customers(0).Name = “Steve Ballmer”
Typed DataSets

They don’t solve all your data modeling needs:




You still have to write code to populate them
Marshalling serializable objects (such as DataSets) rather than
plain strings (such as XML strings) requires more CPU
... but the simplicity and power of using DataSets more
than makes up for it
See IBuySpy reference implementation
ASP to ASP.NET Best Practices

General




If the application is relatively small, consider rewriting
If the application is very large, then plan carefully and migrate
part by part
If you only want to make a syntactic port, then consider only
ASPX pages (that is, not using the “code behind” model) and
do not make unnecessary changes
You do not have to port the whole site at the same time




Consider migrating the slow/critical parts
Remember, you can run ASP and ASP.NET side-by-side
Try to migrate the read-only pages first
Write automated tools to do some tasks
Finally Best Practices...




Use Enterprise Templates that implement and
force good coding practices
Use .Net’s standard naming conventions
Use structured exception handling
Use Typed DataSets rather than “generic”
DataSets whenever possible

It’s not the ultimate panacea but it’s better than
generic DataSets for strong typing and IntelliSense