SSW Foursquare

Rules to Better VB6 Migration to .NET - 3 Rules

  1. Do you know why you should move VB6 applications to .NET?

    .NET is a much better solution than VB6 in the following areas.

    1. Performance is much better as code ultimately gets compiled to the native platform and .NET was designed for performance. Microsoft has many real-world examples that show the performance and scalability of .NET.
    2. As far as size goes, you could be concerned with resource utilization (memory) or the amount of code. As far as resources, VB.NET is similar to VB (and maybe a little heavier for small apps). Part of this footprint is due to the automatic memory management built into .NET, but that is one of the reasons .NET applications exhibit good performance. As far as code goes, you'll write much less code in VB.NET than VB6 since the .NET platform has much more built into it.
    3. VB.NET is designed with asynchronous operations in mind and it's very easy to develop spooling type operations.
    4. ADO.NET (which you'll likely use to provide access to the database) is designed for ease of development with optimal access to data.
    5. Technical Point of view

      1. Standards integration: XML, SOAP, and more In the past, the Microsoft architecture has been built on COM/DCOM, a binary standard for allowing cross-process communication. There was nothing inherently wrong with it, but this binary standard didn't have any relevance outside the Microsoft world. In other words, it didn't allow easy interoperability with other software platforms. In addition to the lack of interoperability with COM, data was another issue. While ADO allowed easy access to data, passing this data from one place to another could be problematic. The ADO Recordset object was a binary structure that stored the data, and once again, this binary format had no meaning to non-Microsoft platforms. .Net seeks to remedy these shortcomings by becoming completely standards-based when required. For example, data is passed across process boundaries as XML, and typically this data has a link to an XSD, so any client can properly validate the data. SOAP is an XML-based protocol that communicates with Web services. The integration of SOAP allows for easy programmatic access by any client, whether or not that client is running a Microsoft operating system.
      2. Ease of deployment One of the major headaches in the COM world has always been deployment. COM makes extensive use of the Windows Registry to locate components on the machine. The concept was good: There would only ever be a single instance of a component registered, and all applications would use the same version. COM promised to have new versions maintain backwards compatibility with old versions, but developers were free to break this compatibility, and sometimes did. .Net takes a different approach: It doesn't use the registry at all. Instead, Microsoft recommends that you make the components (called assemblies in .Net) local to each application. That way, changes to Assembly X for Application Foo won't affect Assembly X's Application Bar. If this sounds like the old days of having multiple copies of the same DLL spread around the computer, it is. But you don't have the same issues of applications looking in the Windows\System32 directory. Because .Net doesn't use the registry, most deployments can simply be done with a copy command. There's often no need to develop installation files. Also, Web applications don't lock assemblies, so you don't have to shut down an application to update a DLL.
      3. Web service support Microsoft is on the Web service bandwagon in a major way, and it's never been easier to develop Web services than it is with .Net. You can create simple Web services with Notepad and not even have to run them through a compiler; simply call them and .Net compiles them and even generates a test page so you can verify they are working. .Net has all the plumbing needed and generates all the files you need, such as the WSDL file. .Net is also a smart consumer of Web services: Once you set a reference to a Web service, you treat it just like a local assembly. You get full Intellisense and function completion help. Web services are great for sending data. Thanks to ADO.Net, Web services can take simple or complex data and send it to any client in a well-formed XML format, complete with a link back to an XSD describing the data schema.
      4. Standard toolset for any .Net language You finally have an integrated set of tools for all your languages. You have a unified IDE, debugger, and other such tools. This allows other companies to plug their languages into the IDE and get all the support of the .Net tools. For example, Fujitsu has created netCOBOL .Net, which integrates directly into the IDE, so you can write Web services and Windows applications in COBOL and receive the debugging and profiling tools provided by Microsoft. .Net is open enough that other vendors can provide their own tools as well. Borland, for one, has said that its next version of Delphi will be able to create .Net applications, but it is almost assured that Delphi will have its own IDE and not plug in to Visual Studio .Net.
      5. Support for mobile devices Soon after the release of Visual Studio .Net, Microsoft released the Microsoft Mobile Internet Toolkit (MMIT) for building mobile applications using .Net. This allows you to visually drag and drop controls on forms aimed at mobile devices. The toolkit handles writing the proper markup language (e.g., WML, WAP, and so forth). Coming soon will be the .Net Compact Framework, a scaled-down version of the Framework designed to run on Pocket PC devices. This will enable developers to create rich applications to run on Pocket PC computers. You can write an application and have it run on small devices, such as a Pocket PC device or a Web-enabled phone. In fact, the MMIT includes a number of emulators that use the actual ROM code for the devices, so you can test how your application will work on those devices before you deploy it.
      6. Managed code .Net manages your code, which is important for a variety of reasons, such as reducing bugs and building more scalable applications. .Net handles such tasks as allocating and recovering memory, creating and destroying threads and processes, and handling the access permissions of the running code. VB developers are used to having such items as memory management and thread and process creation handled for them. For C++ developers moving to C#, having these aspects of their application handled for them greatly reduces the chance for memory leaks and other common bugs. And by having managed code, you get access to all the cross-language capabilities of .Net.
      7. Platform independent While .Net was created for Microsoft operating systems, Microsoft did release a portion of the framework and C# to the ECMA standards committee. The Mono project, an implementation of .Net for Linux, includes the Framework and a C# compiler. This means that many applications, especially Web-based applications, can be written once and then run on multiple platforms.
      8. Modernized languages VB.Net and C# are both modernized languages. They are completely object-oriented and were designed to remove many of the inconsistencies found in VB and C++. The languages were built with an n-tier, component-based approach in mind. C#, for example, removes pointers and other constructs that led to a significant number of issues for C++ developers, especially new developers. VB.Net and C# both benefit from having the Framework manage code. The Framework also includes the base objects needed to allow applications to be multithreaded, XML-aware, and so forth.
      9. Standard base types across languages One of the banes of VB developers has been that a string in VB was not the same as a string in C++, so when calling Windows API functions, there could be some problems. .Net specifies a standard definition for all types, so a string in VB.Net is the same as a string in C#, which is the same as a string in netCOBOL .Net. This means that you no longer have to worry about whether or not an integer is 32-bit in language A but only 16-bit in language B. You can be assured that any data type is the same across languages, enabling better cross-language integration.

    To summarize all these points, Microsoft took all the good parts of their various development languages and platforms and rolled them into .NET. Rapid development from VB, power and control from C++ were combined with a rich set of highly optimized features in the SDK.

  2. Do you use Visual Basic 6.0 Upgrade Assessment Tool?

    Visual Basic 6.0 Upgrade Assessment Tool, is provided to give your organization assistance in identifying common upgrade issues and estimating the cost and effort required to upgrade your Visual Basic 6.0 code. The purpose of this tool is to analyze your Visual Basic 6.0 projects to determine what issues you will need to address to be able to upgrade. It also provides information about where to get help understanding each issue and the types of skills needed to address them.

    The Visual Basic 6.0 Upgrade Assessment Tool generates two Microsoft Excel 2003 files. This first of these is named MainReport.xls and contains a high level look at the results of the assessment.

    • "Defining Project Scope and Priorities." This section explains aspects of your planning efforts that will benefit from the use of this assessment tool.
    • "Application Analysis." This section examines the Visual Basic 6.0 Upgrade Assessment Tool and how to use it to get statistical, structural, and functional information from your applications. You will also learn how to use this information to help you make decisions about the best way to upgrade your applications.
    • "Estimating Cost and Effort." This section explains how to estimate the time and cost of your upgrade project.

    Figure: VB 6 Upgrade Assessment Tool

    Figure: VB 6 Upgrade Assessment Tool

    Figure: VB 6 Upgrade Assessment Tool

  3. Do you use .Net built-in Visual Basic Upgrade Wizard?

    The Visual Basic Upgrade Wizard is a great place to start converting to VS.NET 2005 process. The upgrade happens automatically when you open a Visual Basic 6.0 project in Visual Basic 2005: the Upgrade Wizard steps you through the upgrade process and creates a new Visual Basic 2005 project.

    Figure: Visual Basic Upgrade Wizard

    Nonetheless, there are still some major changes from Visual Basic 6 to Visual Basic 2005, which will require you to rewrite. Data access is probably the largest one, and graphics and printing make a large dent in the total as well. Even with these major changes, though, the Wizard is clearly the place to start.

    Figure: Visual Basic Upgrade Report

    2024 04 13 15 29 58
    Figure: Sample error message

We open source. Powered by GitHub