ISV Community Day

1. ISV Community Day Best Practice Per Ahlberg Developer Evangelist Developer & Platform Evangelism Microsoft Sweden

2. Agenda • General Best Practices • COM Components best practice • Data layer best practice • ASP to ASP.NET Best Practices

3. 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

4. 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

5. 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

6. 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

7. 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

8. RecordSet DataAdapter Command Command Connection Connection ADO  ADO.NET ADO evolves into ADO.NET DataReader DataSet

9. 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

10. 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

11. 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

12. 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

13. .NET .NET VB6 comp VB.NET comp VB6 comp Replacing VB6 components directly After Before Business logic Adapter logic Business logic

14. 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

15. 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

16. 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

17. 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

18. 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+

19. 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

20. 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

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

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

23. 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

24. ASP VB6 comp VB6 comp VB.NET comp Replacing VB6 components indirectly with Remoting Before After .NET Physical boundary Business logic Adapter logic Business logic

25. 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

26. 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 • http://msdn.microsoft.com/library/default.asp?url=/downloads/list/office.asp

27. 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

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

29. 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

30. 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

31. 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