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


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.

Let me know if this helps.


Kind Regards,

Mark Juras | VB6/C# Modernization Architect | www.GreatMigrations.com | 614-638-4632 | Schedule a meeting

  • No labels