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 – migrate the whole tier (middle/presentation) at the same time  Vertical – migrate some pages, some components, at the same time Decide if you want to reuse existing COM components

Migration Best Practices Data access related  If you have a data access tier, move it into.NET COM related  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 DataAdapter DataSet Command Connection RecordSet Command 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

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

.NET VB6 comp.NET VB.NET comp VB6 comp Before After Business logic Adapter logic 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 Replacing VB6 components directly

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

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  Interestingly, the components that a ServicedComponent calls don’t need to be serviced – they use the caller’s context! Use attributes to control configuration  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

.NET VB6 comp.NET Before After Business logic Adapter logic Business logic ASP.NET Web Service Physical boundary Wrapping VB6 components by.NET Web Services

.NET VB6 comp.NET VB.NET comp Before After Business logic Wrapper logic Business logic ASP.NET Web Service Physical boundary 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 Wrapping VB6 components by.NET Web Services

ASP VB6 comp.NET Replacing VB6 components indirectly with Remoting Before After Business logic Physical boundary VB.NET comp Adapter 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  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 Visual Studio ships with PIAs  C:\Program Files\Microsoft.NET\Primary Interop Assemblies Office 2003 PIAs also available  asp asp

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

ds.Tables(“Customers”).Rows(0).Columns(“Name”) _ = “Steve Ballmer” ds.Tables(“Customers”).Rows(0).Columns(“Name”) _ = “Steve Ballmer”Untyped ds.Customers(0).Name = “Steve Ballmer” Typed Typed DataSets Add properties specific to the structured data:  IntelliSense!

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 Typed DataSets

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