What could cause Vb6 run time error 430

Question

I have a COM dll written in vb6. When I try to create a new object of a class module from this dll I get a Run timer error 430: Class does not support automation or does not support expected interface. The interesting thing is that this happens only from outside the IDE, when I am debugging from within the IDE there is no error thrown and the new object of the class is created successfully. What can be the cause?

In general I occasionally get these kind of errors in COM dlls. What is the best way to debug COM issues? How can I know the path of the dll that is being used when a program is running?

Answer 1

This is almost certainly a versioning problem, sometimes known as "DLL hell".

The background is that the .NET world is explicitly designed to let interfaces evolve while keeping the same name. But in the COM world, interfaces are considered to be immutable.

When you're working within the IDE, Visual Studio is creating a new COM Interop wrapper for the COM dll every time you run your solution. But unless you release and replace your entire solution every time, including a brand-new COM Interop wrapper, you're going to run into a versioning issue, where the .NET code is expecting one COM interface but seeing a different one.

EDIT: For some reason, I assumed that you're trying to use the COM component from a .NET component. If the entire solution is actually VB6, then Mr Conley's solution is the recommended approach. Here's a good link that discusses the problem.

Answer 2

If this project is entirely in VB6. The likely cause of this is that the EXE has a copy of the DLL binary in it's directory. When you fire it uses that copy instead of the compiled copy. When you ADD methods or classes that EXE becomes incompatible with the old DLL. If you did a bug fix or just worked with the inside code then EXE will run but it used the old DLL.

Set your DLL to Binary Compatibility. Make sure you have a Compatible directory. Put the DLL of the Last version in there. Point the Binary Compatibility to that DLL. Make sure your EXE compiles to it's project directory. Run the EXE from it's project directory. That way it will use the DLL that you compiled. You need to write a utility so that you can compile every project separately. Test your setup using Virtual PC or another computer.

All these steps will help to avoid DLL Hell. My own project has two dozen ActiveX projects in 6 layers. When I adopted the above my DLL Hell problems dropped to almost nothing.

Answer 3

Read up on binary vs project compatibly.

If you have a shared dll you have to be careful and use binary compatibly. That way VB6 will keep that same COM signature/interface between builds. You have to have a copy of the released DLL for VB6 to compare to - I usually have a separate folder for released binaries. The restriction with binary compatibility is that you can't delete public properties or methods and you can't change their signatures. You can add new properties and methods.

Use project compatibility if you have to make breaking changes (like deleting old public methods) - however if you do that you will have to re-compile all other apps that use the shared DLL.