Upgrading VB6 to VB.Net

This just in. . . a page dedicated to porting VB6 apps to VB.Net

Now that the .Net Framework will be included in each copy of Windows Vista, porting from VB6 to .Net is the last

big pain point I've heard from the MicroISV (Shareware) developers.

Let me know what you think about this!


Comments (5)

  1. Niklas Hemdal says:

    Why move the product to .Net at all (outside of increasing your knowledge portfolio there should be strong business reason)? Juval Lowy is a big fan of interoperating versus upgrading. NOTE: The VB6 runtime ships with Windows Vista and will of course be covered under the same support umbrella? Granted you lose all of the advancement opportunity that .Net offers. The P&P guide is an awesome tome, and the assessment tool is great at analyzing and providing a general level of effort estimate on the upgrade endeavor. You should invest a considerable amount of time in prepping the VB6 source code. Clean out your dead code, removed unused components, review your Win32 API calls for As Any and non intrinsic types, strongly type everything, fix soft-binding problems, and check for things no longer supported (objptr, strptr, etc). No magic numbers, make sure you specify the correct vb constants or 3rd party constants everywhere. Spike all of your 3rd party controls as separate upgrade pilot projects – include the critical 3rd party API calls in the pilot. There might be some special tweaks necessary to get the same behavior from the controls and it’s easier to discover when they are isolated. Look at your form initialization and event handling (activate, combo boxes…). If you make use of DAO/RDO move it to ADO on the VB6 side first. The Option Base issue isn’t such a big deal unless you declare something as having a lower bound of -1, but to be on safe side make sure your indexes start at 1. I have a ton more lessons learned – happy upgrading.

  2. Niklas Hemdal says:

    Oops meant index starting at 0.

  3. Mitchell says:

    I’m glad that Vista is shipping with .NET, but why not new versions of XP? What about 2000, and 98? Those are "officially" supported MS platforms..

    I still have customers using Windows 98, which is still officially supported by Microsoft even 8 years after it’s first public appearance. Many more customers use Windows 2000 and the vast majority, XP. .NET hasn’t shipped with any of those. I can’t imagine everyone is going to switch over to Vista right away so (going by past observation) I’m looking at another decade supporting XP.

    With the release of .NET 2.0, we’ve started the .NET framework deployment counter all the way back to zero. There is no way Micro ISVs can afford to sell software that requires an additional 20 meg download and fairly complex installation when their competitors don’t. Customers are going to take one look at the 30+ meg download or .NET dependency and run away!

    Only with tools like Salamander and Thinstall is developing for the .NET platform going to be feasible for shareware developers and even then we’re starting off at a disadvantage because of the huge file sizes.

    Don’t get me wrong, I think .NET is the best programming platform I’ve ever seen. For web app development it’s hands down the best, but for desktop applications it is still *really* hard for anyone to deploy a .NET application on a large scale. I don’t understand Microsoft’s continued insistance that .NET is the future while making sure that .NET programs won’t work on everyone’s computer.

    Possible interim solutions :

    Make a native compiler. If Hui at RemoteSoft.com can do it, I *know* you guys can.

    Forget the compiler, just make a linker. If Hui at RemoteSoft.com can do it, I *know* you guys can! 🙂

    Make a *real* protector. Again, if Hui at RemoteSoft.com can do it, I *know* you guys can! 🙂

    And the solution to everyone’s problem :

    Make the .NET framework a required update and start bundling it with new installs of XP. It won’t fix the problem right away but it’s a step in the right direction.

Skip to main content