What concerns should I have when instantiating a .NET component in a VB6 application?

Question

I just read through a 2002 article on MSDN called Calling a .NET Component from a COM Component to get a basic understanding of calling .NET objects from VB6 code. However, I still wondering what else I might be concerned about when referencing .NET objects from VB6 and if there's anything newer information than what was available when that article was written 8 years ago.

In our specific implementation, we need to add a component to both a VB6 and a classic ASP (VB Script) application that will apply discount rules to items in a shopping cart. I was planning on writing the solution in .NET and then calling the component from our VB6 app.

However, we're concerned that we might have performance bottlenecks related to translating the ADO recordset to simpler types, instantiating the .NET component to do the work, then translating back to the ADO recordset once we're done. I'm hoping that performance and code maintenance gains by using .NET will outweigh any costs of translating to and from ADO recordsets, but I'm not sure of that; nor am I aware of other concerns that might make a .NET assembly slower than simply using a COM assembly. Any suggestions and insight would be much appreciated.

Answer 1

The main problems I've had in this area are around maintenance; making a COM-callable dll isn't hard, but making it stay callable when you update it (i.e. re-deploying the changes) can be a real pain. Or maybe I just got used to robocopy deployment, which isn't going to be enough in this case - and it didn't help that I had COM+ to contend with as well.

Re the data... you really want to keep the API basic. I would be happy throwing strings over the boundary (xml perhaps, but not the only choice), but I would avoid recordsets etc. That is just asking for pain. Of course, you might not have a choice.

Last time I had to do this, I actually got fed up trying to fight the different layers, and I ended up using http for the interface instead; both VB6 and C# are more than capable of throwing http messages around, or under-pinning a basic http server (either ASP or ASP.NET). Maybe a bit more overhead, but the separation was worth it. And it means I can swap either client or server at any time.