Using Stub Externals

 Create A BuildSet

This page describes the Prototype strategy for handling externals.

1. Create Prototype Assemblies
2. Finishing the Prototype Strategy

 Create Prototype Assemblies

The prototype strategy begins with a migration of your VB6/ASP/COM codebase to .NET such that your VB6 code becomes corresponding .NET code and the referenced COM binaries become .NET projects called Prototype Assemblies.

This collection of application code and prototype code is referred to as a BuildSet because our intent here is to produce a .NET codebase for the entire VB6/ASP Migration Project set that builds right out of the box (with no build errors).

In order to create and validate the prototype assemblies, you run the [Create BuildSet] option against your migration project. This option performs the following operations:

• Run Translation and aggregate a detailed list of external dependencies,
   
• Deploy .NET project(s) for each migration unit,
   
• Generate/Deploy/Build External prototype assemblies, and
   
• Build .NET migration unit project(s)

After the [Create BuildSet] operation is completed you will have a collection of application projects and Prototype Assembly projects sitting in subdirectories of the deployment folder. For example, here are the projects created for the Prototyp2 sample for the ScanTool application:

Prototype External Projects:

• samples\workspace\DemoScanTool\deploy\Extern\gmRTL.Core\MigrationSupport.csproj
• samples\workspace\DemoScanTool\deploy\Extern\MSComDlg_csh\MSComDlg.csproj
• samples\workspace\DemoScanTool\deploy\Extern\MSXML2_csh\MSXML2.csproj
• samples\workspace\DemoScanTool\deploy\Extern\Scripting_csh\Scripting.csproj
• samples\workspace\DemoScanTool\deploy\Extern\TLI_csh\TLI.csproj
  
  

Application Projects:

• samples\workspace\DemoScanTool\deploy\ScanToolLib_pro_csh\ScanToolLib.csproj
• samples\workspace\DemoScanTool\deploy\ScanToolUI_pro_csh\ScanToolUI.csproj
  
  

Note that one of the prototype projects is called gmRTL. This project provides prototypes for various VB intrinsics that do not have a clean, general replacement in .NET.

 Finishing the Prototype Strategy

The prototype strategy is a general means of beginning a migration effort that assumes you wish to take advantage of .NET code to replace external COM components rather than using Interop.

Compared with Interop migrations, teams using the prototype strategy will typically achieve migrations of "build complete" quality faster and with less effort.

Prototype externals provide only a skeleton framework of what is needed; consequently the resulting applications will not run until the prototypes are implemented, i.e., filled in with functional .NET code.. The prototypes are similar to Interop assemblies in that they expose the same interfaces as the original COM types, but they have several key differences:

• They are available as source code
   
• They are simplified to only include the elements of the COM library that were actually used by the source codebase.
   
• They are stubs so they do not call or depend on the original COM components.

Fortunately, there are several options for finishing external prototypes:

• Re-engineering the application code to use a completely different target component -- one that you buy, build, or borrow (from open source or from the .NET framework).
   
• Fleshing out the prototype assemblies as pure .NET code, typically leveraging framework classes, inheritance, or extension methods.
   
• Leveraging Interop where it makes sense.
   
• Use a combination of the above techniques.

The power of this approach is its short time to value and its flexibility in adapting to the unique requirements of different source code and target architecture requirements.