.NET and VB6: is Interop a viable development strategy?_问答_开发者

Is Interop between VB6 and .NET a viable development stra开发者_Go百科tegy?

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.

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?

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:

VB6 has a few test suites but it really isn't testable (certainly not through CI)
.NET has a lot of functionality out of the box, that becomes very hard to do in VB6.
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).

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

If you emphasize the word "strategy", then I must strongly advise, "No!" A strategy would describe your normal or expected plan of attack, and mixing .Net with vb6 is not a recipe for success in that situation. There are several reasons for this, including finding support for the older vb6 tools, the fact that the vb6 runtime is no longer serviced my Microsoft, the increasing difficulty in finding trained vb6 devs over time, the need to find devs that know both platforms... I could go on and on. The point is that you don't want to plan on doing it this way most of the time.

But let's change up your wording a little bit:

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

Ah, that's better. When you find yourself in a situation where you're looking at some existing vb6 code, or you have an experienced vb6 programmer that will need some time to become proficient in .Net, this can be a viable option for a limited duration to address the situation at hand. This is especially true if you can combine it with .Net 4.0, which has some features to make this a little easier.

Just don't make it part of your overall strategy.

Interop between VB6 and .NET is definitely viable (although not desirable).

In our situation, we have a legacy GIS application with several modules. We have been able to move the GIS portion into .NET and are using interop to use the existing code.

It will take several years to rewrite the old VB6 code in C#, and since we can't tell the users to wait that long (our contracts only run for a year and then get renewed), Interop has been the best solution. This way, we can continue to support existing (working) code, while gradually rewriting a module at a time, and while introducing new features (written in C#).

With that said, I have to admit that this has not been a trivial task. We've had to take our old VB6 application exe and change it to an ActiveX exe that our .NET code references, and at the same time our VB6 code has references via Interop to some other .NET code. Some days, I'm amazed what we've done works, but it does, and well!

If I had unlimited money and time, however, I would avoid Interop like it's the ghonnosyphiherpilitis.

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

Only in cases where you have some existent unmanaged code that you cannot migrate. But writing new code on VB6 is not viable.

I think a .NET application consuming a VB6 COM component is viable in some circumstances.

As an example, I had a .NET application that needed to do some fairly complex manipulation of Office documents. This is very difficult to achieve in .NET, as if you're not extremely careful in releasing references, the Office application will fail to quit as described in this KB article.

In this case a pragmatic solution was to create a VB6 component that encapsulated all the Office manipulation, exposing a simplified API to the caller without any of the Office object model.

Craig is not talking about calling COM from .NET, he is talking about

"a VB6 app that interops with some .NET assemblies"

In this situation the answer to the viability question is inevitably "NO".

In the short term you are dealing with various known and unknown runtime challenges -- what you term "cohesion problems" caused by subtle differences in managed and unmanaged environments and the limitations of interop. You also alluded to challenges with deployment. And even in the development stage, we all know that COM components look like black-boxes to the .NET debuggers. It is possible to create and call a CCW in many cases, but not always, and it will take a toll in terms of lower productivity and technical complexity.

The real loss of viability is that in the long term the VB6 app will begin to show its own set of problems. The world of technology is slowly but surely leaving VB6 behind. The supply of willing and able VB6 developers is shrinking and eventually VB6/COM apps will run into incompatibilities and other deficiencies -- in terms of their development, their deployment, and their operation. Eventually the VB6 apps will fail in various ways and it will be difficult to find information and resources on how to fix them in a timely manner. That sounds non-viable to me.

Take the VB6 app to .NET (and minimize direct use of COM from your application layer there as well); you will be glad you did. I also have found that rewriting large VB6/ASP.COM applications for .NET can be done much more efficiently when you employ a methodology that balances manual work with automated transformations rather than insisting you must completely ignore the legacy code and do everything "from scratch".