Q: I observe that the tool-generated C# code ADODB.cs contains only skeletal code and methods. Is this intentional?
Thank you for the question.
gmStudio is designed to help teams complete our Tool-Assisted Rewrite methodology. This methodology begins with a Standard Upgrade where in COM dependencies are satisfied by a stub framework generated by the tool (e.g. the ADODB stub you asked about). The content of the stub framework is based on the COM usage identified in the application code. Standard Upgrade results are typically used for planning the next phase of the upgrade, the Custom Upgrade. In the Custom Upgrade phase, the team will produce results that use .NET types and APIs that fit their standards and budget constraints.
The transition from Standard to Custom translations is described here:
Regarding ADODB specifically, there are many ways for upgrading ADODB to .NET data access:
For each of the above options, teams may use custom translation rules to automatically generate the custom translations, or they may modify the standard translations by hand, or they may blend by-tool and by-hand techniques. The optimal choice depends on your requirements, expected benefits, and time/budget constraints. Generally, the blended approach is the most cost effective, but that depends on many factors.
A sample ADODB emulation (i.e. stub implementation) called MigrationSupport.DataLib is available as a compiled assembly with the gmStudio Samples. The FMStocks sample uses the DataLib sample.
Several articles describing how to develop custom COM upgrades (e.g. for ADODB) are published on our web site:
We also distribute MigrationSupport.DataLib as source with gmStudio licenses. This sample source code is distributed As-Is, No Warranty.
As discussed here: https://portal.greatmigrations.com/display/GMG/Runtime+Library+Requirements+and+Support
Great Migrations can assist you with developing runtime support code subject to a statement of work and measurable acceptance criteria.
No: this is not what is expected. Implementing a stub as an API wrapper is only one possible option. It is also possible to use gmStudio to generate application code that directly references and uses a similar .NET API providing the platform services formerly provided by COM. There are many possible API replacement strategies:
There is no way for us to predict and generalize and implement all of these Custom API Replacement strategies in advance, and they are not done as part of a Standard Upgrade. However, we have generalized the technology to facilitate and automate most types the API replacement work. The amount of cost/benefit of each replacement strategy depends on both business and technical factors.
See this article https://portal.greatmigrations.com/display/GMG/Custom+COM+Replacement and the gmStudio Samples https://portal.greatmigrations.com/display/GMG/Samples
We offer the Standard Upgrade as a first step; it is just a foundation. The Standard Upgrade uses the Stub APIs because they can be controlled and generalized to provide .NET application codes that build. We hope teams will consider using gmStudio to help them to Custom Upgrades after the Standard Upgrade. However, this is not a requirement: you may choose to finish your Custom Upgrade without gmStudio.
No: Stubs may not be identical to the "real API" used by the application:
Stubs are generated based on an Interface Description File (IDF) file generated from an IDL file generated from the COM file referenced. In the case where the COM file is an interop TLB for a .NET assembly, there has already been one transformation made by the tlbexport process where the "real API" (i.e. the .NET assembly) is used to generate a corresponding TLB; that transformation can introduce differences to make the interop TLB more compatible with the COM conventions expected by VB6.
Yes: if the API defined in the assembly is identical to the API declared in the stub, you should able to replace the stub with the assembly. However, if there are differences in the stub and the assembly with respect to API elements referenced in your code, you will probably get compiler errors or warnings. These differences may be addressed by adding migration rules to your upgrade solution to produce code that is compatible with the "real" assembly.
Some shorts are getting translated to ints in the stub, which resulted in a compiler error when I tried to use the assembly
The process that generates the IDF from the IDL converts COM Shorts to Integer by default. This results in ints in the C# stub where the COM has shorts. We do this because we assume most .NET APIs will standardize on int rather than short for fixed point values. However, if the "real API" still uses short, this assumption is not true, the default IDF will not be identical to the "real API". It is possible to generate IDFs that keep COM Short as short. It is also possible to use a RefactorLibrary to override specific API elements so that they have a different type than the one specified in the IDF. I used this for many weak-to-strong typing modifications for the API.
If you need/want to stick with short in your .NET version of the API, I will be happy to re-generate the IDF from the IDL to retain short in the stubs and in the application code that references the API.
The IDF generation based on COM files, not .NET assemblies. In these cases, the COM files are COM-Callable-Wrappers (CCWs) files generated by the .NET SDK tlbexport tool. It might be helpful to look at the process you use for generating those tlb files. I understand the short/int difference and can address that with the TLB, I am not sure about the ref/out matter yet.
We do not require you to use the stubs.
The Windows Common Controls found in MSComctl are NOT standard controls – one must explicitly add a reference to MSCOMCTL.OCX to use them.
The Standard Controls are those that do not require adding a reference to the VB6 IDE Toolbox and/or Project files (e.g. PictureBox, Label, TextBox, etc.).
In a Standard Upgrade, most of the Standard Controls are migrated to their obvious Winforms replacement although the WinForms replacements are not "perfect". Furthermore, some Standard VB6 controls (e.g. DriveListBox, FileListBox, DirListBox, Line, Shape, Data, OLE) are upgraded to Stubs in a Standard Upgrade since there is no obvious, general WinForms replacement.
Our MigrationSupport sample implementation includes sample implementations of DriveListBox, FileListBox, DirListBox that you can see used in the our samples. We also have done a sample implementation of a Data Control. More about that is here: https://portal.greatmigrations.com/display/GMG/Runtime+Library+Requirements+and+Support
It is also possible to configure gmStudio to upgrade these VB6-standard-but-not-WinForms Controls to .NET replacements rather than stubs using Custom Upgrade techniques similar to those used for COM Control upgrades.
Q: RE: I did try your tool on a 9k LOC project, and the result is not as I expected. I see you have prepared a externs folder to contain helper classes like MSFlexGrid, FpSpread... but actually all they do is return null and 0 to avoid compilation errors. Is this a trial-version thing?
A: It is not a trial-version thing, it is a default translation thing. We designed our tool to enable a "Tool Assisted Rewrite" methodology that enables small teams to complete large, complex migrations in a way that provides for a high level of control, precision, and scalability. The default translations are an important initial step in that methodology.
Our process of transforming source code begins with reading and interpreting the original source and storing all the details (symbol tables and operation streams) in a migration model. It is critical that the initial model be accurate and complete. The default translations are in "Standard Upgrade" form: code integrating the application translations with Stub Framework files. Note that the Stub Framework is generated based on the particular COM usage in the source code. We use the .NET compiler to build the default translation and test if it is well-formed, complete, and internally consistent. This is a foundational milestone in our methodology. Please read more about our methodology here: https://portal.greatmigrations.com/display/GMG/Upgrade+Project+Overview
Once the Standard Upgrade milestone is reached, teams typically move on with implementing a Custom Upgrade solution. The Custom Upgrade will contain features such as COM API replacements, structural changes, cleanup, etc. Read about the incremental migration model here: https://portal.greatmigrations.com/display/GMG/Incremental+Upgrade+Cookbook
Custom Upgrade features are supported by the Trial, but they are not activated in a default translation, and at present, they are not activated by clicking check boxes on a GUI. Custom Upgrade rules are implemented by various rules files: XML configuration files and dynamic transformation extensions written in our scripting language or in C# using our .NET API. These "rules" are developed for different upgrade features and integrated to create a full Custom Upgrade. Rules may also be optimized as requirements evolve and may be reused on future upgrade projects at the organization. We have a library of rules files here: https://portal.greatmigrations.com/display/GMG/gmStudio+Extensions and you can see custom upgrades samples here: https://portal.greatmigrations.com/display/GMG/Samples
Our tool provides an open, precise, and flexible COM transformation feature. It is not limited to pre-defined migration targets since different teams have unique requirements. For example, just for Grids there are at least half a dozen replacements to choose from (Microsoft WinForms Microsoft WPF, Telerik, SyncFusion, Infragistics, Xceed, open source, in-house custom). Grids are just one of many COM APIs that may be used in a VB6 application and will need to be replaced. And, all these COM APIs may be upgraded using Custom Upgrade rules defined by the team. A more detailed discussion of this is here: https://portal.greatmigrations.com/display/GMG/Custom+COM+Replacement