Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 8 Next »

Q: I observe that the tool-generated C# code ADODB.cs contains only skeletal code and methods. Is this intentional?

 

A: Yes that is expected and intentional at this point in your project.  This is described in the methodology document I sent you.  
As we have no way of knowing your organization's .NET development standards, we begin with a Standard Upgrade.  The "Standard Upgrade" are a starting point. Typically, you will use them for assessment and planning purposes and then modify the translation rules to produce codes that use .NET types and APIs according to your standards.  That way, you end up with a more maintainable code that follows your technical standards.  

For example, gmStudio can be configured to generate code using various approaches to data access:

  • rewriting the code to use in-house data-access API standard (e.g.. Entity Framework or other)
  • rewriting the code to use System.Data directly  (see the RDO sample on our site and this: http://www.greatmigrations.com/pubs/ComponentReplacement.pdf)
  • rewriting the code to use a .NET emulation of ADODB (e.g. MigrationSupport.DataLib)
  • rewriting the code to use COM interop to ADODB

We distribute a small version of DataLib with the samples.  It is in MigrationSupport.dll.  An example of how to use the DataLib can be found in the FMStocks sample.  

More details  


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:

https://portal.greatmigrations.com/display/GMG/Incremental+Upgrade+Cookbook


Regarding ADODB specifically, there are many ways for upgrading ADODB to .NET data access:

  • Implement the Standard ADODB stubs manually
  • Rewriting the code to use some proprietary in-house or generally available data-access API standard (e.g. Entity Framework or some other ORM)
  • Rewriting the code to use System.Data directly  
  • Rewriting the code to use COM interop to ADODB

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.

More Details 

I understand what’s expected is that I should actually have just filled out the COM stub by forwarding the calls on to Replacement API.

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:

  • something like your replacement .NET assembly which may be nearly identical,
  • a runtime callable wrapper interop assembly (generated using tlbexport)
  • some other managed API from the .NET distribution, from open source, from in-house development, from a commercial vendor,
  • stub implementation by extending/encapsulating/inheriting an appropriate .NET API,
  • or a combination of these options.

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. 

Should the stub API be identical to the real API used by the assembly? If not, why?

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.

If the APIs are identical, should I be able to replace the stub with the real assembly? If not, why?

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.

What would be causing the inconsistencies between the stub and the assembly and how can we fix them? A few examples are

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. 

See https://portal.greatmigrations.com/display/GMG/Author+Interface+Description+Files#AuthorInterfaceDescriptionFiles-RetainingtypeshortforCOMinterop

Can we improve things by sending you the real assemblies we will want to use in the C# project?

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. 

If we have to use the stubs, how can we get around the problem of passing Sketch objects to our other C# components?

We do not require you to use the stubs.

RE: I also have a question regarding standard GUI controls such as those found in MSComctl (not third-party ones). Is it expected that we will replace these controls ourselves (presumably by leveraging the stubs), or can you migrate them to the WinForm equivalents? Or do the stub classes only include things that couldn’t be migrated?


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.

 

  • No labels