I've programmed a Visual Basic dll which is referred to within the Excel VB
after that I've set a reference to this dll within the Excel VBA add
reference dialog. Anything works good until the moment when I compile a new
version of the dll and replace the old one (just by copying). Each time I do
that, Excel reports

error 430 , class doesn't support automation or expected interface.

The only way to have the new dll running, is by removing the existing
reference to the dll first, close the add reference dialog, open the add
reference dialog again and setting the reference to the dll again. Is there
a way to overcome this, or automate these last mentioned activities by
coding ?

regards,
Oscar

Oscar,

I think you need to set the Binary Compatability option in VB under the
compile or make tabs of project properties.

Robin Hammond
www.enhanceddatasystems.com

"Oscar" wrote in message
...
I've programmed a Visual Basic dll which is referred to within the Excel
VB after that I've set a reference to this dll within the Excel VBA add
reference dialog. Anything works good until the moment when I compile a
new version of the dll and replace the old one (just by copying). Each
time I do that, Excel reports

error 430 , class doesn't support automation or expected interface.

The only way to have the new dll running, is by removing the existing
reference to the dll first, close the add reference dialog, open the add
reference dialog again and setting the reference to the dll again. Is
there a way to overcome this, or automate these last mentioned activities
by coding ?

regards,
Oscar

Hi Robin,

thanks for your quick reply. Your suggestion seems to be the solution to the
problem as I concluded after running some tests after that I changed to
Binary Compatibility. There is however one little problem during
compilation. Since I had changed the project name a long time ago and also
changed the arguments of some public class procedures, I receive several
warnings during compilation stating these differences. They advice me to
return to the 'old' projectname and arguments in order to prevent this
message to appear. I was wondering how I can set the Binary Compatibility
check with the new project as reference instead of the old one.

regards,
Oscar

"Robin Hammond" schreef in bericht
...
Oscar,

I think you need to set the Binary Compatability option in VB under the
compile or make tabs of project properties.

Robin Hammond
www.enhanceddatasystems.com

"Oscar" wrote in message
...
I've programmed a Visual Basic dll which is referred to within the Excel
VB after that I've set a reference to this dll within the Excel VBA add
reference dialog. Anything works good until the moment when I compile a
new version of the dll and replace the old one (just by copying). Each
time I do that, Excel reports

error 430 , class doesn't support automation or expected interface.

The only way to have the new dll running, is by removing the existing
reference to the dll first, close the add reference dialog, open the add
reference dialog again and setting the reference to the dll again. Is
there a way to overcome this, or automate these last mentioned activities
by coding ?

regards,
Oscar

Roedd <<Oscar wedi ysgrifennu:

I
receive several warnings during compilation stating these
differences. They advice me to return to the 'old' projectname and
arguments in order to prevent this message to appear. I was wondering
how I can set the Binary Compatibility check with the new project as
reference instead of the old one.


Welcome to com dll hell.

Ignore the warnings and compile the dll. This will become the base dll for
all of your future developments. All past distribution of your project must
be recalled or abandoned. I hope that this will not cause you too much
trouble, but it must be done.

Create a copy of the dll and rename it to [yourdllname].cpt

Now set the binary compatibility of the VB project to this (*.cpt) file.

Remember that from now on you have a contract with your project: You WILL
NOT change names of properties or methods and you WILL NOT change their
arguments. By all means add new properties and/or methods, and hide obsolete
ones, but stick to the contract or you will be back in com dll hell. I've
been there. It's not a nice place.

--
Rob

http://www.asta51.dsl.pipex.com/webcam/

This message is copyright Robert Bruce and intended
for distribution only via NNTP.
Dissemination via third party Web forums with the
exception of Google Groups and Microsoft Communities
is strictly prohibited and may result in legal action.