Skip to main content

How are hybrid VB6/.Net applications functioning in the Real World? [Resolved]

I am maintaining a VB6 application and we are studying how to migrate to .Net We are considering doing this gradually by implementing new features in COM visible .Net classes and migrating existing functionality slowly. I found some instructive 'Hello World' examples about how to do this and it works fine with our App. But how is the real world behaviour of these hybrid applications? Are they stable, maintainable? Particular of our program is that more users on the same computer will use it by switching user accounts.

EDIT: The VB6 app reads data from a USB connection and stores it in an Access database. The user can call up various views on the data. The data is cached in a hardware device, so interuptions in the reading of it are not fatal.

EDIT 4th Oct 2015: Time for a follow up: We still are in the process of replacing the existing VB6 code step by step to .Net. First we took on the data access routines, then the bussiness logic and currently one form after another is converted to WPF. We indeed ended up rewriting every piece of code we converted (in VB.Net), but we could do so slowly and on the same time improving functionality. The hybrid application survived the transition to Windows 8, 8.1 and 10.

EDIT 9th March 2018: We will release the fully converted code next Month. The hybrid application will be supported for at least a year longer. It is showing mainly problems on high resolution screens, but working fine otherwise. To be honest, we have more support headaches due to corrupt .Net Framework installations and corrupt installations of dependencies (SQL Server LocalDb among them) than we have compatibility issues with the VB6 code base...

Question Credit: Dabblernl
Question Reference
Asked March 10, 2018
Posted Under: Programming
3 Answers

I have had amazing success exposing .NET to VB6 via COM interfaces. By doing this we were able to initially refactor out a huge amount of VB6 code and set up an upgrade path to .NET. Just keep in mind that idiomatic VB6 does not translate well to C# or even VB.NET so you'll want to tread carefully.

The one issue we had which was pretty annoying was the excessive amount of rebuilds we had to do because of changes to the public COM interface. This was alleviated by Visual Make.

credit: ChaosPandion
Answered March 10, 2018

FWIW, in my experience the need to upgrade a VB6 app to .Net provides the ideal excuse for a re-write. Unless the original coders were brilliant visionaries, the techniques prevalent in VB6 rarely port cleanly to .Net.

Some of the delights you'll encounter:

  1. You'll end up with references to Microsoft.VisualBasic that you really don't want.
  2. They'll be hard-to-find bugs, for example where the VB6 substring(a,b,c) quietly renders as a.SubString(b,c) and blows up in your face because it was 1-based in VB6 and 0-based in .Net.
  3. All those easy-to-code implicit conversions will come out of the woodwork, usually on the first PC that doesn't have "," as the list delimiter and/or "." as the decimal separator.
  4. Your converted classes won't have the desirable data-hiding that a re-design should bring.


credit: smirkingman
Answered March 10, 2018

It should work fine for you, there's nothing in particular about fast user switching/multiple sessions that should cause you any problems.

In terms of maintainability, keep in mind that hybrid VB6/VB.NET should only be a temporary solution: your plan should be to migrate fully to VB.NET over time.

credit: Dean Harding
Answered March 10, 2018
Your Answer