FAQ


Migration from VB6 to .NET

VB Migration Partner

Technical

Purchasing VB Migration Partner


Migration from VB6 to .NET

  • My VB6 applications work well. Why should I want to port it to .NET?
    • VB.NET is modern programming language that offers powerful object-oriented features that allow you to write code that is more efficient and that can be maintained more easily. More importantly, VB.NET gives you full access to the virtually unlimited power of the .NET Framework and allows you to easily integrate your application with many great features that you can use to extend your application, such as Web Services.

      Even if you don’t need to extend your VB6 application, however, you should seriously weigh the necessity of porting it to the .NET Framework for at least two reasons. First and foremost, your VB6 application might not work correctly under Microsoft Vista or Windows 7! Microsoft has stated that they will continue to support the Visual Basic runtime under future versions of the operating system (but not the Visual Basic IDE), but the key point is that many manufacturer of ActiveX controls won’t offer this degree of support. How many of them have already gone out of business or has discontinued support for their older products?

      The second point to consider is that Microsoft has announced the end of support for Microsoft Visual Basic in March 2008. Microsoft clearly considers “classic” Visual Basic as a dead language. This is the right time to move to the more modern .NET Framework architecture.

      A third important consideration is that VB6 applications are inherently 32-bit and can’t leverage the power of newer 64-bit CPUs and operating systems. Conversely, .NET programs run well in both 32-bit and 64-bit modes, because the .NET Framework Just-in-Time (JIT) compiler generates the right CPU opcodes and the most efficient code in all cases. The performance boost can be quite significant for some kinds of code. Also, your users will perceive the “64-bit” tag as a clear indication that your app uses state-of-the-art techniques, which in turn will help sales.
  • I read that .NET applications are slower than VB6 applications, because they are interpreted. Is that true?
    • It’s a false myth. All .NET compilers produce the so-called IL (Intermediate Language) code, which is just-in-time-compiled (or JITted) one instant before it is executed and then runs at the highest speed. You can also use the NGen tool provided with the .NET Framework to compile the entire application at deployment time, so that you avoid the JIT-compilation.

      In most cases, migrated .NET applications run as fast (or as slow) as the original VB6 program. In half of the remaining cases .NET executables are faster than VB6 apps (for example, in array and object creations), in the other cases VB6 is faster. For 99% of the tasks that a business application performs – such as building the UI, interacting with the database, and so forth – speed differences are quite negligible.

      There is only a minor exception to the abovementioned general rule: when you access COM objects from .NET you pay a small speed penalty, because the call goes through COM Interop, a layer of the .NET Framework that handles data marshaling between the managed (.NET) and unmanaged (VB6) world. This happens, for example, when you access the fields of an ADO Recordset. However, in most cases the COM Interop overhead is negligible; if it not, you should move to ADO.NET technology as soon as possible after you have completed the migration to .NET.
  • Can VB Migration Partner convert to C#?
    • VB Migration Partner can currently convert only to VB.NET, and supports VB2005, VB2008 and VB2010. We plan to add support for C# in 2010.
  • I also read that Visual C# is better than VB.NET. Shouldn’t I migrate to C#, then?
    • The supposed supremacy of C# over VB is a false myth, fed mostly by C++ zealots who moved to C# and love putting curly braces everywhere. It is true that the first edition of C# had a few keywords that VB 2002 didn’t have, but the gap has been filled in VB2008. As of this writing, virtually all major C# features are supported by VB.NET as well.

      What many detractors of VB seem to (deliberately) ignore is that all .NET Framework languages are compiled to basically the same IL opcode sequence and that the JIT-compiler compiles this sequence to virtually the same sequence of CPU instructions. The bottom line: VB.NET is a first-class .NET citizen that is as fast as C# or any other .NET Framework language. You can read more about VB health here and here.

      Going a bit more deeper: The only thing that C# has and that VB.NET hasn’t is support for unsafe code, that is the ability to generate code that can’t be verified by the .NET Framework’s CLR. Unsafe code can speed up execution in some cases, but it deprives your application of some important benefits. As a matter of fact, very few C# developers use unsafe code at all. You can read more about the differences in syntax between the two languages here and here. Even when developers find out the IL that the two languages generate isn’t exactly the same, they assert that the differences don’t justify choosing one language over the other.
  • What are the pros and cons of an automatic translation tool vs. manually rewriting the application from scratch?
    • The decision of using a code translator vs. rewriting the application from scratch should be based mainly (if not exclusively) on the balance of benefits and costs. If you have unlimited time, skill, and money, the re-writing approach is undeniably the way to go. In most real-world scenarios, however, you need to go to the market as soon as possible, have money constraints, don’t have a team of experienced .NET developers, and can’t afford to scrutinize each and every line of code and/or write thousand of unit tests to ensure that the .NET application behaves like the original one.

      In some cases, the time-to-market factor shadows all other considerations. For example, if the VB6 application doesn’t run well under Microsoft Vista – because of incompatible 3rd-party ActiveX controls or issues with Vista's security model – you might lose an unbearable number of sales opportunities until the full rewriting process is completed.

      Another factor that should be weighed accurately is whether the original VB6 application must continue to evolve during the migration process, as it’s often the case with business applications that are continuously update to comply with customers’ requests, current laws, etc. In such scenarios, keeping the migration time as short as possible becomes a critical factor.

VB Migration Partner

  • What is VB Migration Partner?
    • VB Migration Partner is an innovative tool that converts VB6 applications to VB.NET. It has been designed from the ground up using advanced parsing algorithms and dramatically reduces the overall time and cost of the migration process.
  • Who wrote it?
  • Visual Studio comes with a free VB6 conversion tool. Why should I pay for a similar product?
    • When measuring the cost-effectiveness of the automatic migration approach, all depends on the specific translator. If the translator doesn’t have a high success rate, many developers (correctly) estimate that cost/time savings don’t compare favorably with the opportunity of re-designing the application from the ground up.

      The Upgrade Wizard that comes with Visual Studio does a good job in translating VB6 code to VB.NET, but it fails to correctly convert several VB6 language features that VB Migration Partner fully supports. Our tests on a random sample of applications downloaded from the Internet show that VB Migration Partner generates up to 10-15x fewer compilation errors than the Upgrade Wizard. VB Migration Partner can convert most of the language features that have been considered as “not automatically convertible”, such as Gosubs, arrays with nonzero lower index, As Any and callback parameters in Declares, auto-instancing variables, deterministic finalization, and more. We do believe that VB Migration Partner makes the difference when converting large business applications.
  • How can VB Migration Partner reach such a high success ratio?
    • Three main factors contribute to VB Migration Partner’s superior performance. First, unlike some tools that are based on generic conversion engines that have been tailored to handle VB syntax, VB Migration Partner’s parser engine has been designed from scratch with the only purpose to understand VB6 syntax. Second, VB Migration Partner comes with a comprehensive support library that eliminates (or greatly reduces) the differences between the two languages. For example, VB Migration Partner can convert VB6 applications that use graphic statements, custom coordinate systems, drag-and-drop, Windows subclassing, DAO, RDO, and ADO data binding (including variations such as ADO data source and data consumer classes), and a lot more. Third, VB Migration Partner recognizes the so-called migration pragmas.
  • What are migration pragmas?
    • Migration pragmas are special remarks that developer can insert in the original VB6 code to drive the migration process and to help VB Migration Partner to generate better .NET code. For example, pragmas can dictate how auto-instancing variables must be translated, whether an object requires deterministic finalization, or if support for default properties in late-bound mode is necessary. Pragmas can be used also to optimize the resulting application and decide what kinds of warnings VB Migration Partner should emit.
  • How does it relate to other migration tools, such as Code Advisor and Upgrade Assessment Tools?
    • In addition to the Upgrade Wizard included in Visual Studio, Microsoft offers two tools that can be useful during the migration process. Code Advisor quickly scans a VB6 application and highlights code constructs that can’t be converted to VB.NET; the Upgrade Assessment Tool provides a cost estimation of the migration process.

      VB Migration Partner embeds and augments the functionality of these two utilities. In fact, VB Migration Partner matches the Upgrade Assessment Tool’s features, in that it allows you to generate project metrics, export them to Microsoft Excel, evaluate cost and time of the entire process, and customize the report as you see fit. (Notice that this feature requires that Microsoft Excel be installed on the local computer.) As for the Code Advisor tool, VB Migration Partner parser and code generation engine is so fast that it can convert an entire VB6 application, calculate code metrics, and optimize the resulting .NET code in about the same time that Code Advisor takes to create its reports.
  • Do I need to be a .NET expert to leverage VB Migration Partner’s full power?
    • For sure, a certain degree of familiarity with both the source and the target language helps during the migration process. This is true for all conversion tools. However, VB Migration Partner doesn’t strictly require that you are a VB6 or a .NET guru because the support library hides most of the differences between the two languages. For example, VB Migration Partner automatically converts graphic methods even if the .NET way to implement them is completely different from the VB6 way, and doesn’t require that you study all the nitty-gritty details of the GDI+ portion of the .NET Framework.

      To recap, VB Migration Partner allows you to have a running .NET application without having to train the *entire* your team before facing the migration effort. This detail alone makes VB Migration Partner a clear winner over the free Upgrade Wizard and other conversion tools.
  • How does VB Migration Partner manage large VB6 business applications?
    • In many ways. First, unlike the Upgrade Wizard tool, VB Migration Partner supports the migration of VB6 project groups, a feature that saves time during the conversion of large projects consisting of two or more projects and assures that cross-project calls are converted correctly. Second, VB Migration Partner includes sophisticated code analysis techniques that let developers mark unused classes and methods, so that they can focus on the code that actually needs to be converted. Third, VB Migration Partner can generate reports that include code metrics and estimation of the time and cost of the migration process. If your app is divided in dozens or hundreds distinct VB6 projects, you can use VB Migration Partner's command-line version for batch conversions and generate a single report file that shows the result of each individual project.

      Last but not the least: VB Migration Partner lets you do your chores in less time simply because it’s much faster than other similar tools: it can be up to 8 times faster than the Upgrade Wizard and can convert 300 to 400 lines per second on a 3GHz system. (Notice that this timing includes additional tasks such as advanced code analysis, dead code detection, code refactoring, and creation of code metrics.)

      Here's another feature that is essential in converting large N-tier applications split in multiple projects: VB Migration Partner can optionally preserve all project GUIDs when it regenerates a VB.NET project. If you have one or more Visual Studio 2005/2008/2010 solutions that include that project, all references are correctly preserved and you don’t have to manually rebuild the solution.
  • I need to extend and improve the VB6 application while the migration process proceeds. Does VB Migration Partner handle such a requirement?
    • All the other migration tools we are aware of force you to work on a “snapshot” of the original VB6 application; if you later extend or modify the VB6 code, the converted .NET application won’t include all these fixes and enhancements. If the migration process takes weeks or months – quite a reasonable assumption for real world business applications – the neat result is that the .NET application is already outdated by the time it finally compiles and runs correctly. VB Migration Partner copes with this issue by introducing the concept of convert-test-fix cycle.
  • What is the convert-test-fix cycle?
    • Typically, migrating a real-world VB6 application is an iterative process that goes through the following three stages. First, you convert the original VB6 code and test the result; odds are that the converted .NET project contains invalid code that causes compilation errors, thus you must understand how to fix the original code to avoid these errors. However, instead of modifying the VB6 application or the converted .NET application, VB Migration Partner allows you to just add one or more pragmas to the original VB6 code: pragmas are just remarks, therefore they can’t affect the way the VB6 application works. You can then re-submit the “pragma-enhanced” VB6 project to VB Migration Partner, see the results, and add more pragmas if necessary, and continue this process until no more compilation errors occur.

      When the converted .NET project compiles correctly you are now at about the middle of the migration process, because you can now actually run the .NET project and see how it behaves. Again, odds are that you’ll experience runtime exceptions or other sorts of malfunctioning. You take note of these problems, understand how to avoid them – our Knowledge Base is the best source of information for this purpose – and fix the original VB6 code by adding more pragmas. Next, you convert the VB6 code again, test the result, and fix the original code with more pragmas until the code both compiles and executes correctly.

      It is essential to notice that during all the iterations of the convert-test-fix cycle the original VB6 code is untouched (except for the added pragmas, which are just remarks and don’t affect how the VB6 application behaves), therefore all features and bug-fixes added to the original code in the time window necessary to complete the migration process are converted to .NET as expected. Only a migration tool that supports pragmas (or equivalent mechanism) can guarantee that the converted application is always in synch with the original VB6 code.
  • Can the convert-test-fix cycle really handle all migration issues?
    • Pragmas are usually enough powerful to convert any VB6 application into a .NET solution that has no compilation errors. Pragmas are also useful to get rid of most runtime errors and misbehaviors, but realistically they can't solve all the problems that might occur after the conversion.

      For example, pragmas can’t help if the original application uses the DataReport designer or one or more unrecognized ActiveX controls. In such cases, you must manually fix the converted .NET application. If you postpone such manual fixes at the end of the automatic conversion process you can reduce to the minimum the period during which the original VB6 and the converted .NET applications are out-of-sync.
  • What are extenders?
    • VB Migration Partner has an open architecture and supports plug-ins (or extenders) that can participate and alter the migration process to add support for special features. An extender is a class that implements a special interface that VB Migration Partner recognizes and uses to communicate with the extender. The extender class must be compiled in a DLL and deployed in VB Migration Partner’s main directory.

      Right out of the box, we provide an extender that eliminates unused constant and Declare statements and another extender that refines the code produced by the conversion of UserControl classes. You can enable or disable individual extenders from the Extenders tab of the Options dialog box.

      In our vision, we plan to use extenders both to add new features to VB Migration Partner and to ease the migration of large and complex business application. For example, the migration of a VB6 application that uses a custom-made library could be improved by writing an extender that recognizes calls to that library and converts them appropriately.

      Writing an extender isn’t a trivial task and requires us to fully document the entire VB Migration Partner’s object hierarchy. As of this writing (early November 2007), we have no definite plans about when the Extender SDK library will be publicly released. In the meantime, Code Architects is willing to provide custom support to customers who have special needs that might be fulfilled by means of extenders.
  • Our VB6 application doesn’t clearly separate the user interface, the business logic layer, and the data layer. Can your tool help in this respect?
    • An automatic translator can’t do much to change the overall architecture. You can solve this issue only by rewriting the application. Strictly speaking, it isn’t a “porting” any longer and isn’t a “re-writing from scratch” either, because existing users expect that the new application behaves as closely as possible to the original one and you can’t completely change the way they interact with the user interface.
  • Where I can learn more about VB Migration Partner?
    • We plan to offer the best technical support through the www.vbmigration.com web site. We are making all the documentation available on the Internet, including training videos and code samples. A section of the web site is devoted to “generic” migration topics: we will share our knowledge with all VB6 developers who wish to migrate their code and their skills to .NET Framework and VB.NET, even if they aren’t interested in VB Migration Partner. For example, check out the list of differences between VB6 and VB.NET, many of which have been never documented anywhere else.
  • What if I need more assistance during the migration process?
    • Code Architects Srl, the makers of VB Migration Partner, is willing to provide the best custom support for large migration processes, regardless of whether you plan to use our tool. We are based in Southern Italy and we can travel to anywhere in Europe, or even overseas. In most practical cases, however, we can offer a good level of support remotely, via phone, Skype, email, chat, etc. Send us an email for more information.

Technical

  • Which Visual Basic versions does VB Migration Partner convert from?
    • VB Migration Partner converts applications written in VB6. If you have an application authored in VB5 or earlier version, you must convert it to VB6, ensure that it compiles and works correctly, and finally convert it to .NET using our tool.

      VB Migration Partner doesn’t convert other Visual Basic “dialects”, such as VBA and VBScript. Active Server Pages (ASP) applications aren’t supported either, because they use VBScript.

      We firmly believe that Active Server Pages applications should be redesigned and re-written from scratch as ASP.NET applications. Being VBScript a subset of VB6, converting ASP code would be a simple task; however, we don’t offer this option because we don’t want to encourage migration practices that we don’t recommend.
  • Which Visual Basic .NET versions does it convert to?
    • VB Migration Partner can generate Visual Basic 2005, Visual Basic 2008 and Visual Basic 2010 applications. We do not plan to support the 2002 or 2003 edition of Visual Basic .NET.
  • Do I need VB6 or Visual Studio .NET on the computer where I install VB Migration Partner?
    • VB Migration Partner uses components from both Visual Basic 6 and Visual Studio 2005, 2008 or 2010, therefore it is required that both products be correctly installed on the computer where you install VB Migration Partner. If they aren’t, a runtime error occurs when you launch the first migration attempt.

      Of course, this requirement doesn’t apply to .NET applications produced by VB Migration Partner. After you compile such applications, they only require that the .NET Framework be installed on the computer where they run. (In a few special cases, these compiled apps may require that the VB6 runtime be installed, as explained here.)

      If you are perplexed about installing VB6 and Visual Studio .NET on the same computer, please read this Knowledge Base article from Microsoft.
  • Can I test VB Migration Partner even if I haven’t purchased Microsoft Visual Studio yet?
    • VB Migration Partner works well with both Microsoft Visual Studio and Microsoft Visual Basic Express, so you can test VB Migration Partner with the less powerful Visual Basic Express. Visual Basic Express is free and can be downloaded from Microsoft web site.
  • Which Windows versions does the tool support?
    • Current version of VB Migration Partner is written in VB2005 and therefore can run on all Windows versions on which .NET Framework 2.0 and Microsoft Visual Studio 2005 can be installed (Both 32-bit and 64-bit versions are supported, where applicable). The same holds true for .NET applications that are produced by VB Migration Partner. Please check Microsoft web site for more information.
  • Which VB6 controls does VB Migration Partner support?
    • All the 60+ controls that come in the Visual Basic 6 package, with only two exceptions: the OLE Container control and the Repeater control. The so-called “windowless” controls (e.g. WLText and WLCommand) are also supported, as are a few controls and type libraries that aren’t shipped with Visual Basic 6 but are often used by VB6 developers, such as the WebBrowser, ScriptControl, the Scripting library, and the VBScript Regex engine.

      In this context, supporting a control means that all major features of the control are correctly converted and behave as expected in the .NET application. However, some features might not be supported: for example, we don’t support the Customize, SaveToolbar, and RestoreToolbar methods of the Toolbar control and the vertical orientation for the ProgressBar control.
  • Which VB6 features aren't supported?
    • VB Migration Partner doesn’t support WebClass components, DHTML Page classes, DataReport classes, a few undocumented functions (VarPtr, StrPtr, and ObjPtr) and a few, less important control properties such as DrawMode, ClipControls, and Palette.
      UserDocument and PropertyPage classes aren’t supported directly: they are converted to .NET UserControls, therefore developers can easily reuse them in a different context.
  • Why these features aren’t supported?
    • The actual reasons may vary. For example, WebClass and DHTML Page components have been used in relatively few VB6 commercial applications, thus we decided to focus our efforts on the features that have been used more extensively. In addition, we believe that server-side applications using WebClass components should be converted to ASP.NET applications, because only ASP.NET ensures that you take full advantage of the .NET Framework.

      The DataReport hasn’t been used in many business applications because most VB6 developers preferred more powerful 3rd-party reporting tools such as Seagate’s Crystal Report, thus we decided that supporting DataReport classes wasn’t essential. We don’t support UserDocument and PropertyPage classes because they don’t fit the .NET Framework architecture. Remaining unsupported features were simply impossible or way too difficult to implement in a robust way under .NET.
  • Do converted .NET applications depend on COM and ActiveX components?
    • The majority of controls used by converted .NET applications are fully managed controls and don’t depend on any ActiveX control or COM-based technology. The only controls that depend on the original ActiveX control are: DataGrid, MSHFlexGrid, MS Char, MM Control, MSComm, INet, MAPISession, MAPIMessage, Winsock, and ScriptControl.
  • Are converted applications “true” .NET Framework executables?
    • Yes, absolutely. VB Migration Partner generates native .NET applications that can be loaded inside Microsoft Visual Studio and modified or extended as needed. You can add new forms, add standard .NET controls to form migrated from VB6, use any class in the .NET Framework, make the application Internet-enable by adding support for Web Services, and so forth.
  • Do converted .NET applications require a support library?
    • All applications generated by VB Migration Partner require that the CodeArchitects.VBLibrary.dll file be deployed with the .NET executable. The support library is essential to support features that have no counterpart in .NET – control arrays and DataEnvironment classes, for example – or that are implemented in a completely different way (graphic methods or data binding, just to name a few).

      It should be noted that also applications converted with the Upgrade Wizard may require a companion library – more precisely, the Microsoft.VisualBasic.Compatibility.dll library – to support features such as control arrays, resource files, and a few controls that have no counterpart under .NET - namely, DriveListBox, DirListBox, and FileListBox. We just decided to improve on this concept and created a support library that can account for virtually all the VB6 features that .NET doesn’t support natively.
  • Do converted .NET applications depend on Visual Basic 6 runtime?
    • No, with one minor exceptions: VB6 applications that use the Printer object, the Print common dialog, or the Winsock control do require a small component written in VB6, which in turn requires that the Visual Basic 6 runtime be installed on the end user’s computer. You can get rid of such dependency by implementing printing and winsock support by means of .NET Framework native classes and methods.

      If you never use the Printer.hDC property, however, you can easily modify the generated VB.NET app so that it uses the Printer object exposed by Microsoft’s VB Power Pack library, and you can use the standard Printer dialog that comes with .NET. Therefore, unless you use the Printer.hDC property, in practice the generated VB.NET project has a dependency on the VB6 runtime only if it references the Winsock control.
  • Can VB Migration Partner convert 3rd-party ActiveX controls?
    • Yes, it can. We provide a command-line tool named AxWrapperGen, which you can use to create wrapper classes for ActiveX controls that VB Migration Partner doesn’t support out of the box. You can fine-tune, modify, and extend these wrapper classes – if necessary – and control how properties of the original ActiveX controls are imported or translated. Finally, you just need to compile the wrapper classes into a DLL and drop it in a directory recognized by VB Migration Partner (VB Migration Partner recognizes DLLs located in its installation folder or in any directory mentioned in an AddLibraryPath pragma), so that the next time you run the tool it will recognize the additional controls. (An individual DLL can provide support for multiple ActiveX controls.)
  • What about ActiveX controls authored in VB6?
    • VB Migration Partner can convert UserControls authored in VB6. Nearly all features are supported, including advanced one such as the Extender object, Ambient properties, graphic methods, and more. VB Migration Partner even generates XML comments and Description attributes for properties and supports UserControls that work as data sources (for example, a custom Data control). Our knowledge base includes a few tips for improving UserControl classes after converting them to .NET and we even provide a special VB Migration Partner extender to generate a more “polished” code for UserControl components.
  • What is the best migration strategy if the VB6 applications uses *a lot* of ActiveX controls?
    • VB Migration Partner replaces a 3rd-party ActiveX control with a placeholder control (a picturebox control with red background); for obvious reasons the tool can’t correctly migrate references to the control’s properties and methods. To complete the migration process, you can choose among three different strategies.
      1. If the control is used sparingly, it makes sense to migrate the application and then manually replace placeholder controls with the .NET control that more closely resemble the original ActiveX control. This strategy delivers a “native” .NET Framework application, but doesn’t support the convert-test-fix methodology. (In other words, your manual fixes are lost if you re-convert the application.)
      2. You can use the AxWrapperGen tool to generate a .NET control that wraps the original ActiveX control. VB Migration Partner then uses the .NET control to replace all occurrences of the ActiveX control. This approach does support the convert-test-fix cycle, but delivers a .NET Framework application that still depends on ActiveX controls. Worse, a small number of ActiveX controls occasionally crashes when used via COM Interop, thus this approach might not be applicable to all controls in a real-world business application.
      3. in a more radical approach, you write a 100% managed control that has same members and behavior as the original ActiveX control. (This is the approach we adopted for nearly all the controls in our support library.) While wrapping hundreds of properties and methods of an ActiveX is a complex task, in practice most VB6 applications use only a small fraction of these members, thus this task is often easier than expected. (Of course, Code Architects can help in this effort.).). In practice, you can modify the wrapper class generated by AxWrapperGen so that it derives from a real .NET control rather than the original ActiveX control.
      Interestingly, mixing the first two strategies can often be a reasonable approach: you use the ActiveX wrapper during the migration and test process (to leverage the convert-test-fix cycle) and then replace the ActiveX control with a “native” .NET Framework control once all other issues have been solved.
  • Do you plan to provide support for additional ActiveX controls?
    • We plan to provide support for more ActiveX controls and upload them to www.vbmigration.com as soon as they are available. We are planning to provide a “native” version of the DataGrid control – current control is just a wrapper on the VB6 DataGrid ActiveX control – and make it available after version 1.0 of VB Migration Partner is released.
  • Can VB Migration Partner convert MTS/COM+ applications?
    • VB Migration Partner converts MTS/COM+ components written in VB6 into .NET classes that inherit from System.EnterpriseServices.ServicedComponents, with the proper Transition attribute. In addition, calls to the most important and widely used objects in the COMSVCSLib type library – namely ContextInfo, ObjectContext, SecurityProperty  - are converted into calls to .NET methods. If a VB6 app uses only these objects, then the reference to COMSVCSLib typelib is dropped and the .NET project has no direct dependency on it; else, this typelib will be referenced also by the converted .NET application.

      Additionally, VB Migration Partner recognizes the IObjectConstruct interface and generates the correct code that allows an MTS/COM+ component to retrieve the construction string passed to it by the COM+ infrastructure.
  • Can VB Migration Partner convert NT service applications?
    • VB6 developers can run their applications as NT services by using the NTSVC.OCX control. We plan to add support for this control in the future, possibly by means of a VB Migration Partner’s extender.
  • Do converted .NET applications run under Microsoft Vista and Windows 7?
    • Yes, with two caveats. First, a few .NET and Windows API methods might require you to disable User Access Control (UAC) features under Microsoft Vista, else the call would fail. (This action would be necessary also to run the original VB6 application under Vista.)
      Second, if your VB6 application uses 3rd-party ActiveX controls, the converted .NET application uses a wrapper for that ActiveX control and we can’t guarantee that the ActiveX control works well under Microsoft Vista or Windows 7. If in doubt, you should either ask the manufacturer of the ActiveX control or thoroughly test the original VB6 application under recent versions of the Windows operating system.

      Please notice that VB Migration Partner uses wrappers for all the ActiveX controls that come with VB6, for example DataGrid and MS Chart. Microsoft made a statement that these controls work well under Microsoft Vista.
  • Do I need administrative privileges to run VB Migration Partner?
    • VB Migration Partner requires access to areas of the registry and the file system – most notably, the System32 directory where most ActiveX controls are installed – therefore it is required that it runs under administrative privileges and – if running under Microsoft Vista – that User Access Control (UAC) be disabled.

      The current beta version refuses to work correctly if these requirements aren’t met. The release version will prompt the user to escalate privileges when the program is launched.
  • Can VB Migration Partner generate ASP.NET applications?
    • No, because the ASP.NET programming model is too different from VB6 model for an automated conversion tool to achieve a significant success ratio. However, it is technical possible to convert VB6 forms to equivalent ASP.NET forms, therefore we might provide a plug-in that converts just the user interface layer to ASP.NET in the future. Our final decision depends on how many customers are interested in converting VB6 forms to ASP.NET.
  • Can VB Migration Partner generate Windows Presentation Foundation (WPF) applications?
    • We might add support for WPF forms and controls.

Purchasing VB Migration Partner

  • What is the VB Migration Partner edition that fits my needs?
    • We offer an “off-the-shelf” version of the product and a “custom” version that can be tailored to the specific VB6 applications that must be migrated. The Professional Edition is the best choice for small-to-medium size VB6 applications that don’t use advanced language features and don’t require some sophisticated features, such as support for MTS components. The Enterprise Edition is targeted to medium-to-large size VB6 applications that need VB Migration Partner’s full power and is targeted to large ISVs and corporate developer teams that need to convert large applications and need the highest degree of training, customization, and support. You can find a feature comparison table here.
  • How much does VB Migration Partner cost?
    • The price of VB Migration Partner depends on a number of factors, including the total size of the applications to be migrated, the number of user licenses, and whether you are interested in any optional modules.

      Please download our free VB6 Bulk Analyzer tool, run it over your VB6 source code, and send us the generated report. VB6 Bulk Analyzer can process all the files in one or more directory trees, therefore you can create a single report for all the VB6 projects that make up your application. In return you’ll receive a price quotation, a summary of all the challenges you’re going to face in your migration process, which ones can be easily solved by VB Migration Partner, and which ones might require some additional work.
  • What are the terms of the end user license agreement (EULA)?
    • Not counting the usual legal stuff, by purchasing our tool you basically agree on the following terms: You can’t convert someone else’s VB6 projects, unless they also own a copy of VB Migration Partner. To clarify: VB Migration Partner consists of two distinct pieces, the actual converter and the support library. If you own an application that has been converted from VB6 using our tool (and therefore requires the support library) then you must purchase a VB Migration Partner’s license, even if the actual conversion job was done by an external consultant or a 3rd party company. This restriction holds true regardless of whether you have converted the VB6 project for internal use or if you are reselling it to end users.
  • Is the support library's source code available for purchase?
    • The support library is provided as compiled, optimized VB.NET code and there's no technical reason for purchasing the support library's source code. From a conceptual point of view, the support library has the same role of the .NET Framework library: you can extend it by inheriting from its classes or by adding new classes, but you never need to modify its source code. Moreover, even a minor change in the library's code might introduce subtle bugs and we wouldn't be able to support any .NET application that uses a modified version of the support library.

      However, we are willing to license the support library’s source code, if your company policy require that you can access the source code of any 3rd party software. For more details and price, please contact us.


Follow Francesco Balena on VB6 migration’s group on

LinkedIn



Read Microsoft Corp’s official case study of a VB6 conversion using VB Migration Partner.



Code Architects and its partners offers remote and onsite migration services.

More details



Subscribe to our free newsletter for useful VB6 migration tips and techniques.

newsletter


To learn more about your VB6 applications, run VB6 Analyzer on your source code and send us the generated text file. You will receive a detailed report about your VB6 applications and how VB Migration Partner can help you to quickly and effectively migrate it to .NET.

Get free advice


A fully-working, time-limited Trial Edition of VB Migration Partner allows you to test it against your actual code

Get the Trial



The price of VB Migration Partner depends on the size of the VB6 application, the type of license, and other factors

Request a quote



Migrating a VB6 application in 10 easy steps

Comparing VB Migration Partner with Upgrade Wizard

Migration tools: Feature Comparison Table

All whitepapers


Home | Overview | About us | Blog | Newsletter | Privacy Policy | Contact us