FAQ


Migration from VB6 to VB.NET

VB Migration Partner

Technical

Purchasing VB Migration Partner


Migration from VB6 to VB.NET

  • My VB6 applications work well. Why should I want to port it to VB.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! 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, VB.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 VB.NET applications are slower than VB6 applications, because they are interpreted. Is that true?
    • It’s a false myth. The VB.NET compiler produces 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 VB.NET applications run as fast (or as slow) as the original VB6 program. In half of the remaining cases VB.NET is faster than VB6 (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 VB.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 case 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 VB.NET.
  • 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 another 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 with VB2005 and continues to be filled in the forthcoming 2008 edition.

      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 things 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 (or 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 VB.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 – 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 regulations, 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 VB.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 tools. 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 VB.NET code in about the same time that Code Advisor takes to create its reports.
  • Do I need to be a VB.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 VB.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 VB.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 VB.NET application without having to train *all* 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.

      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.)
  • 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 VB.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 VB.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 VB.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 VB.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 VB.NET project compiles correctly you are now at about the middle of the migration process, because you can now actually run the VB.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 VB.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 sufficient to convert any VB6 application to a VB.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 really 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 VB.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 VB.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?
    • Clearly, a 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 VB.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 both Visual Basic 2005 and Visual Basic 2008 applications. We do not plan to support the 2002 or 2003 edition of Visual Basic .NET. (Note to beta testers: current beta version emit VB2005 projects by default; they can generate VB2008 projects by tweaking an entry in the configuration file.)
  • Do I need VB6 or VB.NET on the computer where I install VB Migration Partner?
    • VB Migration Partner uses components from both Visual Basic 6 and Visual Studio 2005, 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 VB.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 VB.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 VB.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 VB.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), the “classic” drag-and-drop (as opposed to OLE drag-and-drop, which *is* supported), and minor control properties such as DrawMode, ClipControls, and Palette.
      UserDocument and PropertyPage classes aren’t supported directly: they are converted to VB.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 VB.NET.
  • Do converted VB.NET applications depend on COM and ActiveX components?
    • The majority of controls used by converted VB.NET applications are fully managed controls and don’t depend on any non-.NET control or 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 VB.NET applications “true” .NET Framework executables?
    • Yes, absolutely. VB Migration Partner generates native VB.NET applications that can be loaded inside Microsoft Visual Studio and modified and 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 VB.NET applications require a support library?
    • All applications generated by VB Migration Partner require that the CodeArchitects.VBLibrary.dll file be deployed with the VB.NET executable. The support library is essential to support features that have no counterpart in VB.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 VB.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 VB.NET doesn’t support natively.
  • Do converted VB.NET applications depend on Visual Basic 6 runtime?
    • No, with one minor exception: VB6 applications that use the Printer object or the Print common dialog 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 support by means of .NET Framework native classes and methods.
  • 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 you can 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. Most advanced features are supported, including 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 VB.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 paradigm. (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 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 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.)
      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 also 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 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 VB.NET applications run under Microsoft Vista?
    • Yes, with two caveats. First, a few VB.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 VB.NET application uses a wrapper for that ActiveX control and we can’t guarantee that the ActiveX control works well under Microsoft Vista. If in doubt, you should either ask the manufacturer of the ActiveX control or thoroughly test the original VB6 application under Microsoft Vista.

      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?
    • Not yet. We plan to add support for WPF in year 2008.

Purchasing VB Migration Partner

  • When is VB Migration Partner going to be available for purchase?
    • As of this writing (November 2007) we are beta testing the tool. We plan to have the release version 1.0 within mid-May 2008.
  • How can I participate to VB Migration Partner’s beta program
    • The beta program has ended on March 15th, 2008. Current beta testers will continue to receive minor releases and bug fixes until version 1.0 is released.
  • 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 runtime library. If you own an application that has been converted from VB6 using our tool (and therefore requires the runtime 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.
  • OK, I am convinced. How much does the release version cost? Where can I buy it?
    • We haven’t finalized the price list of VB Migration Partner. As of this writing (November 2007) we are planning to offer an “off-the-shelf” version of the product and a “custom” version that is 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.

      The Professional Edition will be available for purchase at www.vbmigration.com. If you are interested in the Enterprise edition or in custom-made versions of our tools, please send us an email, with a short description of your company and of the application(s) that you plan to convert to VB.NET. It is especially important that you mention what are the challenges you expect to face during the conversion process, so that we can advise you about the best strategy for your migration plans.
  • What is the Early Adopter Program (EAP)?
    • By mid-May 2008 we plan to launch an Early Adopter Program, reserved to beta testers and software companies who want to complete the migration of their VB6 apps as soon as possible. These companies will receive version 1.0 and dedicated tech support from Code Architects. We haven’t decided yet how long the EAP will last. You can read more information by subscribing to our newsletter or reading our blog.
  • Is the source code available?
    • Not yet, but we plan to make the source code of the support library available to customers of the Enterprise Edition.

Subscribe to our newsletter for more VB news, tips, and techniques.

newsletter



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