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 Page History

Version 1 Next »

Q:  Given the absence of reported errors or warnings during the migration of ScanTool, can I assume that there won't be a need for any manual adjustments? Furthermore, if I intend to build and run this .NET code within Visual Studio, should I expect a smooth process? (Note: I am not able to find a .exe file in deploy/bin) In the event that there were any errors during the migration, could you please direct me to the location within the tool where I can access a detailed error report? When the translator reports the translation was a SUCCESS it means that no errors were reported by the translation process. 

A: Generally speaking you should always expect to make additional adjustments to complete your upgrade. However, making adjustments is usually done by changing the rules and translating again. 

  • Successful translation results reflect the VB6/COM source code, the rules, and the gmStudio version used. 
  • By default, gmStudio uses rules that produce a direct translation of the application code and a stub framework that reflects the VB6/COM services used in the code. 
  • The default translations are a first step in our methodology; their goal is to build in .NET without errors, and their purpose is help verify that the tool properly recognizes and interprets the VB6/COM source code.
  • The default translation will not run and may not look complete in the forms designer.  That is expected.
  • In order to produce code that runs, each upgrade team must define and prepare upgrade rules that direct gmStudio to produce a custom translation that uses .NET APIs and language conventions that meet the team's coding standards. 
  • A typical upgrade project will have many types of custom rules: COM API replacement, structural improvements, optimization, integrating hand written code, etc…
  • With an appropriate set of rules the .NET code will be maintainable, will run,  and will follow the team's coding conventions.  The details vary from team to team and application to application…
  • You may learn more about the methodology and how to customize gmStudio here.  https://portal.greatmigrations.com/

gmStudio does not produce a detailed error report telling you how to rewrite your code.  However it can produce a variety of detailed reports describing the source code and the translated code that can help you plan your upgrade effort.  Ultimately each team should define their project objectives and technical requirements based on their standards, budget and constraints.  Rewriting VB6 for .NET software is not one-size-fits all; gmStudio is a tool to help you more efficiently and accurately rewrite your code, not constrain how to rewrite the code.

For example, here is a screen shot of the default (OOTB) ScanTool UI translation.  Note that all of the controls are in the Document Outline even though the DriveListbox and FolderListbox render as transparent rectangles. This version does not run because it is linked to a stub framework.

Here is  screen shot ScanToolUI translated using the custom rules provided with the WinForms ScanTool sample solution.  This version renders properly in the designer and runs using actual .NET framework code.

And here is the same ScanToolUI sample translated using the custom rules provided with the WPF ScanTool sample solution.  The WPF version uses XAML rather than as Designer.cs file.  This version also runs. 

All of these examples report a successful translation, but they all produce different results reflecting the rules used.



  • No labels