Home VB Migration Partner Resources Migration services FAQ Blog Contact us FAQ Migration from VB6 to .NET My VB6 applications work well. Why should I want to port it to .NET? I read that .NET applications are slower than VB6 applications, because they are interpreted. Is that true? Can VB Migration Partner convert to C#? I also read that Visual C# is better than VB.NET. Shouldn’t I migrate to C#, then? What are the pros and cons of an automatic translation tool vs. manually rewriting the application from scratch? VB Migration Partner What is VB Migration Partner? Who wrote it? Visual Studio comes with a free VB6 conversion tool. Why should I pay for a similar product? How can VB Migration Partner reach such a high success ratio? What are migration pragmas? How does it relate to other migration tools, such as Code Advisor and Upgrade Assessment Tools? How does VB Migration Partner compare to other commercial VB6 converters? Do I need to be a .NET expert to leverage VB Migration Partner’s full power? Can VB Migration Partner manage large VB6 business applications? I need to extend and improve the VB6 application while the migration process proceeds. Does VB Migration Partner handle such a requirement? What is the convert-test-fix cycle? Can the convert-test-fix cycle really handle all migration issues? What is the Trace-Match methodology? What are 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? Where I can learn more about VB Migration Partner? What if I need more assistance during the migration process? Why does VB Migration Partner emit more warnings than Microsoft Upgrade Wizard? Technical Which Visual Basic versions does VB Migration Partner convert from? Which Visual Basic .NET versions does it convert to? Do I need to run VB Migration Partner on a computer where VB6 is installed? Do I need to run VB Migration Partner on a computer where Visual Studio .NET is installed? Can I test VB Migration Partner even if I haven’t purchased Microsoft Visual Studio yet? Which Windows versions does the tool support? Which VB6 controls does VB Migration Partner support? Which VB6 features aren’t supported? Why these features aren’t supported? Do converted .NET applications depend on COM and ActiveX components? Are converted applications “true” .NET Framework executables? Do converted .NET applications require a support library? Do converted .NET applications depend on Visual Basic 6 runtime? Can VB Migration Partner convert 3rd-party ActiveX controls? What about ActiveX controls authored in VB6? What is the best migration strategy if the VB6 applications uses *a lot* of ActiveX controls? Can VB Migration Partner convert MTS/COM+ applications? Can VB Migration Partner convert NT service applications? Do converted .NET applications run under Microsoft Vista and Windows 7? Do I need administrative privileges to run VB Migration Partner? Can VB Migration Partner generate ASP.NET applications? Purchasing VB Migration Partner How much does VB Migration Partner cost? What are the terms of end user license agreement (EULA)? Is the support library's source code available for purchase? Is it possible to get a Trial? What do I have to do to get your free advice for a successful migration? Is technical support included in the license price? May I extend the subscription period? We provide migration services to 3rd party companies. Can we later transfer the license to our customers? What kind of guarantee do you offer that VB Migration Partner will correctly convert my VB6 application to .NET? How many years will VB Migration Partner library be supported? There will never be a charge for the support library? 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 have discontinued support for their older products? The second point to consider is that Microsoft ended support for Microsoft Visual Basic in March 2008. Microsoft clearly considers “classic” Visual Basic as a dead language. It 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 are two important exceptions to the abovementioned general rule. First, 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. Second, string concatenations may be much slower or much faster under .NET, depending on which .NET string you use. The .NET Framework comes with two different string flavors: the standard String object and the StringBuilder object. If you perform hundreds or thousands concatenations on the same string, the standard String object can be many times slower than the VB6 string, and this fact has gained .NET with the reputation of being slower. On the other hand, if you use the StringBuilder object your .NET concatenations can be much faster than in VB6. (Incidentally, please notice that VB Migration Partner automatically spots the code portions that would greatly benefit from using a StringBuilder. You can replace a String variable with a StringBuilder variable by just inserting one pragma.) Can VB Migration Partner convert to C#? Yes, VB Migration Partner can convert both to VB.NET and C#. It supports Visual Studio 2010 and 2012 (when converting to either language) as well as Visual Studio 2005 and 2008 (when converting to VB.NET) I read that Visual C# is better than VB.NET. Shouldn’t I migrate to C#? 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. The main problem of migrating from VB6 to C# is that C# lacks a few essential VB6 features (that are included in VB.NET). More specifically, C# lacks native support for On Error Goto and On Error Resume Next. VB Migration Partner compensates by generating code that in most cases behaves like the original VB6 code (and generates warning if the C# code isn’t perfectly equivalent). Nevertheless, the lack of support for these two keywords is responsible for C# code that is less concise and readable than the VB.NET code that VB Migration Partner generates in the same circumstances. The bottom line: if your VB6 code heavily uses On Error statements, we recommend that you use the Trial Edition of VB Migration Partner to convert to both VB.NET and C#, and see whether the C# version is OK for you. Notice that all VB6-to-C# migration tools suffer from the gap that exists between these languages. Unlike other VB6-to-C# converters, however, VB Migration Partner leverages the many features added in C# 2010 – most notably, dynamic variables and optional parameters – and can therefore generate C# code that is far more efficient, concise and maintainable than our competitors. 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 if you don't migrate to .NET as quickly as possible. 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? Code Architects’ VB Migration Partner is a five year effort by a team of top-notch Visual Basic and .NET Framework developers led by Francesco Balena, renowned speaker and author of seven books for Microsoft Press, including Programming Microsoft Visual Basic 6 and all the books of the Programming Microsoft Basic series down to Programming Microsoft Visual Basic 2005. The developer in charge for the user interface and the report features is Marco Bellinaso, author of the best selling ASP.NET 2.0 Website Programming: Problem - Design - Solution. Marco’s TheBeerHouse application has been selected by Microsoft for inclusion in the official list of ASP.NET Start Kit Web Sites. Giuseppe Dimauro, MSDN Regional Director for Italy and co-author of Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Developers by Microsoft Press, took care of fine-tuning, testing and hardcore debugging together with a great team of senior and junior developers. Read more about Code Architects and the VB Migration Partner Team here. 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 may (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 barely decent 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 assortment of VB6 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. 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 virtually eliminates 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), DDE (Dynamic Data Exchange) protocol, 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. Pragmas can be defined at the solution, project, file, method, and individual variable lever, a granularity that offers huge advantages over conversion tools from other vendors, which only offer project-level settings. For example, you can have a group of project-level pragmas that establish the general conversion rules, plus a few other pragmas that handle exceptions to these rules inside specific files or methods. 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. How does VB Migration Partner compare to other commercial VB6 converters? VB Migration Partner was officially launched in May 2008, but we began working on it in January 2006. At that time there was only another VB6 converter on the market, namely Artinsoft VB Upgrade Companion, which had no competitors to be worried about. We were newcomers to this market and of course worked very hard to deliver a product that had to be significantly better that theirs, otherwise all our work would have been void. As of this writing, any unbiased test can prove that VB Migration Partner has more features and is more powerful than any other converter on the market. Our competitors are trying to catch up and now release new versions much more frequently than in the past, yet they still have to match the majority of features we introduced in version 1.0, such as support for Gosubs, graphic statements, drag-and-drop, and others. In spite of our technical advantage, we continue to relentlessly improve VB Migration Partner and add great features at each new release, such as the great Trace-Match methodology that allows you to dramatically reduce the time you spend to establish functional equivalence with the original VB6 application. No other vendor in this market segment is so reactive to customers’ needs. 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 your *entire* 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. Can VB Migration Partner manage large VB6 business applications? Sure, 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 other converters that use the same engine as Upgrade Wizard and can convert 1-20000 lines per second on a modern computer. (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/2012 solutions that include that project, all references are correctly preserved and you don’t have to manually rebuild the solution. Finally, VB Migration Partner even allows you to migrate only a fraction of an existing VB6 project, for example just a few forms or a single module. This important feature allows you to focus your attention on a form or a class at a time, which means that you don’t have to worry on the hundreds compilation errors that you might receive if migrating a huge VB6 project in one shot. Needless to say, no other VB6 converter offers anything similar. I need to extend and improve the VB6 application while the migration process proceeds. Does VB Migration Partner handle such a requirement? All migration tools from other vendors 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 is the Trace-Match methodology? When migrating from VB6 it is essential to ascertain that the generated code preserves full functional equivalence with the original application. However, “proving” that such equivalence is preserved is easier said than done. In many cases, just comparing the result on the user interface or the data stored in the database isn’t enough, because you are seeing the final effects, not all the intermediate steps. It’s hard to reach the certainty that the converted code will behave like the original VB6 code in all circumstances. Trace-Match methodology is a new VB Migration Partner (added in version 1.32) that can help you in determining that the VB6 and the .NET code work exactly in the same manner, create objects and invoke methods in the same order, use the same values for private variables, and so on. From a technical perspective, Trace-Match is the combination of a VB6 tracing library, a .NET tracing library, and the ability to automatically insert (and remove) thousands trace statements by means of a simple click. Once all the trace statements are in place, you just need to perform a set of test cases on both the VB6 app and the converted .NET app, and check that the produced trace files are identical (or at least, very similar). Trace Match also comes with basic profiling features, thus it’s easier to immediately detect when the original or the converted application spend most of their time. Trace output can go to a file or be displayed by means of a tool such as DebugView. 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. We 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. 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 made 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 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, 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. In addition, Code Architects offers migration services, so that you can let us migrate your VB6 application in your behalf. Read here for more information. Why does VB Migration Partner emit more warnings than Microsoft Upgrade Wizard? In general VB Migration Partner emits more migration warnings than Upgrade Wizard (included in Visual Studio 2005 and 2008) or other VB6 migration tools from other vendors, a detail that might mistakenly bring you to the conclusion that VB Migration Partner is less precise than other tools on the market. The truth is just the opposite. In fact, just counting the number of warnings is simply misleading. The reason for this abundance of messages is that VB Migration Parter is able to spot many more potential errors than its competitors, which in turn allows you to anticipate many incorrect runtime behaviors that would bring to exceptions or just bogus results. To give an idea of how many potential problems Upgrade Wizard ignores, just browse this page and this page. Next, keep in mind that – unlike other VB6 migration tools – VB Migration Partner lets you decide which warnings should be emitted and which ones should be hidden – by means of the DisableMessage and DisableMessages pragmas – therefore you are always in control of the output from the migration process. Finally, consider that most warnings are related to code analysis features; these warnings hightlight inefficiencies in the original VB6 code - methods that are never invoked, unreachable code, unused variables, ByRef parameters that can be safely transformed into ByVal parameters, etc. – and aren’t really related to potential runtime errors. These warnings provide useful information to make the .NET code smaller and more efficient, however they can be safely ignored during the first phases of the migration. (Or you might just suppress them, as explained above.) 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, 2008, 2010 and 2012 projects. Do I need to run VB Migration Partner on a computer where VB6 is installed? It isn’t strictly necessary, but we recommend it for two reasons. First, the ability to edit and re-compile the VB6 application while fixing some recurring migration issues makes the migration process easier and speedier. Second, running VB Migration Partner on the same computer used to develop the VB6 application ensures that all file paths and registry entries are correct, that the right version of all type libraries is found, and so forth. In fact, VB Migration Partner might exhibit a few issues when converting a VB6 project that has been copied from another computer. Notice, however, that during the conversion process VB Migration Partner does use components written in VB6, therefore it is required that the VB6 runtime be installed on the computer where you install VB Migration Partner. If this requirement isn’t met, the setup process might fail. Do I need to run VB Migration Partner on a computer where Visual Studio .NET is installed? VB Migration Partner uses a few utilities that come with Microsoft Visual Studio, therefore we consider Visual Studio as a prerequisite for successfully carrying out the migration process. 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? VB Migration Partner run on all Windows versions on which .NET Framework 2.0 and Microsoft Visual Studio 2005, 2008, 2010 or 2012 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 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. VB Migration Partner even supports some controls from third-party vendors, such as the Active ThreeD Plus suite from Sheridan (now Infragistics). Unlike what other conversion tools do, supporting a control means that all major features of the control are correctly converted and behave as expected in the .NET application. For example, by stating that VB Migration Partner supports the PictureBox control we mean that it supports all its graphic methods, all drag-and-drop events (in both “classic” VB3-style and OLE flavors), data-binding, DDE, the ability to work as a container for other controls, and a lot more. No other conversion tool on the market supports all these features. Which VB6 features aren't supported? VB Migration Partner doesn’t support WebClass components, DHTML Page classes, DataReport controls, a few undocumented functions (VarPtr, StrPtr, and ObjPtr), and minor 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 – 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 with 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? Converted .NET projects have no dependency on Visual Basic 6 and its runtime. 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.) We have prepared two whitepapers on this topic: A smart approach to 3rs-party ActiveX control conversion explains the basics of AxWrapperGen, whereas ActiveX controls and wrapper classes is a step-by-step tutorial that guides you through the conversion of a control. 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 unrecognized 3rd-party ActiveX controls with placeholder controls (i.e. picturebox controls 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. If the control isn’t used in each and every form of the application, 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.) 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. 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. 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. At this time we don’t support this control, therefore the migration of Windows service applications requires some manual labor. 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. 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. In our opinion, all existing tools that claim to offer such a feature don’t generate .NET code that meets the quality standards that are required for real-world software, in terms of efficiency and maintainability. Purchasing VB Migration Partner 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 requires that you can access the source code of any 3rd party software. For more details and price, please contact us. Is it possible to get a Trial? Yes, you can have a fully-working, time-limited Trial Edition of VB Migration Partner that allows you to test it against your actual code. Contact us to receive the personalized link to download it. What do I have to do to get your free advice for a successful migration? To get our free advice and 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, prepared by a team of VB6 and .NET skilled developers led by VB guru Francesco Balena, about your VB6 applications and how VB Migration Partner can help you to quickly and effectively migrate it to .NET. Is technical support included in the license price? VB Migration Partner’s license comes with a 6 month subscription period, during which you can submit any technical question related to our software and you will be able to download any new 1.xx version of VB Migration Partner, including any other ancillary component we have uploaded to our web site in the meantime. At the end of the subscription period you will still be able to download any new version of the 1.xx support library, so that you won’t have to fix your migrated code if a future version of Windows or the .NET Framework is partially incompatible with your migrated code. May I extend the subscription period? Yes, the subscription period can be further extended. Please contact us for more details. We provide migration services to 3rd party companies. Can we later transfer the license to our customers? If you are an independent consultant or a company that provides migration services, you need to purchase a VB Migration Partner license to do the migration on your computer(s). However, once the migration is over you can freely transfer your license to your customer. However, it is essential that you inform us by email or fax, so that we can deactivate your license and activate theirs. What kind of guarantee do you offer that VB Migration Partner will correctly convert my VB6 application to .NET? Unfortunately, no code conversion software – regardless of its source and target language – can be proved to work flawlessly in all circumstances. Just think that all competing VB6-to-.NET tools on the market don’t even attempt to convert features that are fully supported by VB Migration Partner, for example graphic statements, drag-and-drop, and DDE. It is true, however, that your VB6 application may include portions that won’t work well after the migration to .NET, for a variety of reasons. For example, your project might use one or more ActiveX controls that don’t work when hosted on a .NET form, or it might rely on one of the few VB6 features that VB Migration Partner doesn’t support, such as UserDocument or HTML Pages. The simplest and fastest way to understand whether VB Migration Partner supports a given feature or control is browsing and searching our massive online documentation. We put together a detailed manual and a huge collection of Knowledge Base articles that describe what VB Migration Partner support, and what it doesn’t. This is much more than any other competing product currently offers. But there is another, simpler way to check whether VB Migration Partner can fulfill your needs: just ask for a Trial Edition and see it for yourself. VB Migration Partner Trial Edition has no limitations in the size of VB6 projects it can convert and includes virtually all the features of the Full edition. The only limitation is that the Trial Edition has an expiration date, yet you have enough time to test it against the most challenging portions of your code. Best of all, Trial Edition users have full access to tech support, thus you can also test the quality of the team of developers behind VB Migration Partner. How many years will VB Migration Partner library be supported? We plan to support it for at least 8 years, or until Microsoft will support VB.NET or Windows Forms (depending on which event will happen first). Of course, if for any reason Microsoft will not support anymore VB.NET or Windows Forms, the migrated application will not be supported; so the real problem will not be our support library. At any rate, Microsoft always supports a technology for at least 10 years after it has been declared obsolete. As of 2010 VB.NET and Windows Forms are still supported, therefore we don’t anticipate any problem in this area. There will never be a charge for the support library? VB Migration Partner’s support library is royalty free and it will always be, period. In addition to being royalty-free, registered VB Migration Partner’s user have the lifetime right to download any future 1.xx release of the library. Such future releases will include all bug fixes, performance optimizations, and other minor features. Follow Francesco Balena on VB6 migration’s group on search 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 Code Architects S.r.l. © 2014 - all rights reserved