.NET and VB6: is Interop a viable development strategy?

Question

Is Interop between VB6 and .NET a viable development strategy?

I am working on a VB6 app that interops with some .NET assemblies, but the combination of 'cold-start' and other cohesion problems makes for a non-smooth result.

Answer 1

EDIT - narrowed down my answer a bit.

Is it possible? Yes, certainly.

Would I recommend it? Certainly not!

The stereotypical situation (which I've encountered a number of times) is that you have some component written in VB6 five or ten years ago. The author has left the company, and while the problem the app is solving is fairly simple and well understood, the app itself is not; nobody in the company really knows how to maintain it and/or it's poorly written and difficult to maintain in the first place.

If your situation looks like that, then I would recommend a port - especially if your company is short on VB6 resource and has plenty of .NET resource. As MarkJ says that's not necessarily a universal opinion, but it rings true with my own experience.

Addressing the MS post at:-

http://msdn.microsoft.com/en-gb/dd408373.aspx#migrate3

MS say that rewriting from scratch is usually more costly than either extending or automatically migrating (using the tools linked). I've certainly used the Visual Basic Upgrade Wizard to get a starting point, although we've usually been porting to C# rather than to VB.NET. It's an excellent place to start - particularly if you've got a preference for VB.NET.

Lastly:-

Normally we would only recommend [a rewrite] for a small number of situations including:

• The original application has many problems resulting from bad architecture, design and/or coding practices. Symptoms may include poor scalability or performance, poor user interface and difficulties in maintaining the code.
• The original application no longer matches the needs of the business in significant areas. A core change is required, e.g. the user interface must be delivered by the browser rather than as a smart client.
• The company already has significant skills in .NET gained on other applications and the application is well understood and relatively small.
• Source code is no longer available for significant parts of the application.

Those are all excellent points, however if you couldn't identify at least one of those issues in your project - the application works fine and is maintainable, the changes you need to make are small, the company has plenty of VB6 resource, and you've got access to the source code - I'd probably be asking why you want to move to .NET at all. In every relevant project I've worked on, we've encountered two of the first three issues (if not all three of them).

If porting isn't an option at all, then we need more info. What kind of app is it? What's the VB6 doing? What's the .NET doing?

Answer 2

We have a large project that we started adding .NET functionality to over 5 years ago and it has been working perfectly. Initially we started by just adding non-visual components, slowly moving the business logic into .NET for many reasons:

1. VB6 has a few test suites but it really isn't testable (certainly not through CI)
2. .NET has a lot of functionality out of the box, that becomes very hard to do in VB6.
3. The plan was to port to .NET when we got the time.

The .NET components (written in C#) where so successful we started writing visual components in C# (using the interop toolkit and the C# Interop toolkit), as well as even WPF components. Here is where things do get a little sketchy, sometimes having three message pumps, and components from 3 technology stacks leads to quirkiness (components disappearing from the screen or not properly refresshing) and brutal hacks (sendMessage to specific components, LockWindowUpdate here and there) to get things working. However for an APP that most of our clients think is written in WPF, that has won countless industry awards, and is being used daily by tens of thousands of customers it is a tribute to how resilient (even if incredibly painful) VB6 is and how good the Com/.NET interop story that Microsoft created (heck Visual Studio 2010 is almost the same Franken monster its just C++ Com/C#/ and WPF).