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?
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.