Change in dll trows runtime 430

I have a project in VB6 with an ActiveX dll.
This is a demo with one class with one member:
After compiling and building I created a cab package and installed it on a computer. It runs fine.
Now I changes something in the dll and overwrite the dll with the new one on the target box. The only difference is that the one and member returns another string. Interface is the same, class is the same, everything is the same except for another size return of the string.
The app now trows an error that it could not find a matching interface. Interface is the same. Or is there another interface somewhere or are there other steps to be taken in stead of replacing the dll?
Who is Participating?
rmichelsConnect With a Mentor Commented:
But you have changed the interface, if you have changed what is returned or a parameter on the function.

You have a couple of choices:

1) Rebuild the app, and connect it to the latest DLL interface and rebuild you CAB files.

2) Create a new function that returns the data you want, leaving the old function in place.  This should not create a "new" interface, since old app will still run against the existing DLL functions.  (of course that depends up what compatibility you are running).

phiroAuthor Commented:
Hi rMichels.
Thanx for answering my question.
I want to clarify my problem a bit,

My project was a test as to check into the behavior of the dll. I had one method in the class MyClass:

Public function Hallo() as String
  Hallo = "Hallo"
End Function

In the next version I replaced that with :

Public function Hallo() as String
  Hallo = "Hallo allemaal"
End Function

So you see, that neither signature nor the return value of the method is changed. As far as I know, there is no change in interface.
As to your possibilities you gave:
1)  I do not want to rebuild, i am experimenting with changes in functionality without recompiling the application. For instance, my dll hold the buisiness logic, and by replacing the dll I want to be able  to update the logic without doing something with the rest of the app.
2) An extra function would inply I need to introduce new calls from the app ergo, rebuilding it as well.

I do understand that perhaps this is not possible, or that I should use regular Dll's in stead of ActiveX dll.
Do you know more of this?

Regards PhiRo

Sometimes VB just screws up like that, and the only solution is to break binary compatibility. A nuisance, but that's the way it is...

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

phiroAuthor Commented:
Goeiemiddag Caraf_g

So it would appear I need to write this in a regular C dll... Too bad, there goes a fine idea. I will try to build a ActiveX exe and check whether the same behavior appears That sucks because it's performance is inferior to an in-process server. Or else I would have to encapsulate it all into a COM object. Do you have any experience with changing COM objects without recompiling the container app?

And rmichels? Any ideas?
What compatibility option do you have set, under project settings?  You should set binary compatibility to avoid a new GUID being generated every time you compile.

You you are correct, you did not change the interface..I misunderstood your initial question.
phiroAuthor Commented:
That was it!
I still got the compatibility set  at project level. The interface of the ActiveX dll appears to have a CLSID as well. At project compaitibility this gets renewed as well
Mucho thanks!!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.