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