430 Class does not support Automation with custom ActiveX DLL

Posted on 2003-10-29
Last Modified: 2008-02-01
Having trouble with an ActiveX DLL I built.  I've had the DLL and the client application working without incident until just recently.  The two projects work fine in the development environment and on my machine.  I can load them under a Project Group or independentally without incident.  As soon as I distribute them to another workstation in the office, that workstation gets 430 and is completely fried.

I had binary compatibility set on the DLL but decided I needed to make a change to the interface - basically I wanted to expose another method.  I changed the code and recompiled the DLL as a new file (the original My.DLL is now being compiled as My2.DLL).  The public classes kept the same names within the project and the project name stayed the same but the name of the DLL was changed.  I went back and set binary compatibility to the new DLL and compiled again.

At this point I'm losing my mind.  I have tried editing the registry on one workstation to remove references to the older versions of the DLL.  I have recompiled multiple times.  I started a brandnew project and imported the classes and forms from the original with a new project name, new DLL name and new names for my public classes.  I tried building a new test client application and over and over all I see is

  RTE 430 Class does not support Automation....
  Occasionally I'm seeing Class Factory cannot supply requested class (or something like this).  MSDN had no references to that, by the way.

Is there a way to determine exactly what the interface of my DLL consists of?  Like which methods are exposed and what parameters they take (besides using Intellisense)?  I know next to nothing about IUnknown and QueryInterface  - I leave that to my C++ friends - but could the solution be hidden in that interface?

The breakpoint happens when I try to Set the local object, as in:
  Set JM = New My2.Dll.PublicClass

I was able to see the breakpoint by running a test app on the dev environment from a workstation that has never compiled the DLL, and thus has a 'clean' Registry.  I referenced the complied DLL in the WinSys folder in this instance.

Anyway, I'm stuck.  Any thoughts are appreciated....
Question by:jmerritt
  • 3
  • 2
LVL 15

Accepted Solution

SRigney earned 500 total points
ID: 9642496
You sound like you are in .dll hell.  I'll give you the easy way out without.

Open the ActiveX Dll application.  
Set Compatibility to No Compatibility and recompile.
Set Compatibility to Binary Compatible with the new one and save the project.
Close the project.

Open the front end.
Change the reference to point at the .dll just compiled.
Recompile the front end.

Redeploy to the other pc.

What probably happened is that when you recompiled the application last time the and then changed the compatibility you changed it to be compatible with the original version again.

A few notes on compatibility.
1. You only need to break compatibility when removing an existing public method or changing the parameters or return type of an existing public method.
2. You can add new functions without breaking compatibility.  Any existing application that references the .dll will continue to work, they just won't realize that the new functions exist (unless they are recompiled).

Author Comment

ID: 9642636
Thank you for your quick response.  I'm ready to try your suggestion.  Just a couple of quick questions:
1.  I have 7 available references in my client app:  different names for the various DLLs I've been trying to create to work around this and different locations.  What is the easiest way for me to clean that mess up?
2.  I'm trying to follow your first set of instructions but I'm not sure I totally understand.

'Open the ActiveX Dll application.
  I open my project:
       File:  SMS_TXLet70.VBP
       Name:  SMS_TXLet70
'Set Compatibility to No Compatibility and recompile.
  I do this and create:
       DLL:  SMS_TXLet70.DLL
'Set Compatibility to Binary Compatible with the new one and save the project.
  What do you mean by 'the new one'?  Should I be setting Binary Compatibilty and browsing to the SMS_TXLet70.DLL that I just created in Step 2 or renaming the DLL at this point to create a new reference in the Registry?
Sorry to be so obtuse but my head has been spinning since yesterday afternoon and I'm under some pressure to get a fix.  ...the benefits of being given an office without a door on it!

LVL 15

Expert Comment

ID: 9642826
'Set Compatibility to Binary Compatible with the new one and save the project.
  What do you mean by 'the new one'?  Should I be setting Binary Compatibilty and browsing to the SMS_TXLet70.DLL that I just created in Step 2 or renaming the DLL at this point to create a new reference in the Registry?

Yes set compatibity to binary, then browse to the one that you just created.  This step is really not necessary at this point, but will set up the compatibility for the next time that you have an internal code change in this project.

As for cleaning up your 7 other references I don't know what they are all used for.  
You will want to remove the one reference to SMS_TXLet70.DLL then close the reference window.
Reopen the reference window and browse to find the .dll that you just created in the previous step.  Select that one (to ensure that you are using the correct one). And close the reference window.

Author Comment

ID: 9643442

You've restored me from Sniveling Idiot to Psuedo TechGeek here in my office.

Thanks for giving me somebody to lean on...
LVL 15

Expert Comment

ID: 9643714
You're welcome.  I just come here and do this because I like the gratification I get helping others.

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Most everyone who has done any programming in VB6 knows that you can do something in code like Debug.Print MyVar and that when the program runs from the IDE, the value of MyVar will be displayed in the Immediate Window. Less well known is Debug.Asse…
Background What I'm presenting in this article is the result of 2 conditions in my work area: We have a SQL Server production environment but no development or test environment; andWe have an MS Access front end using tables in SQL Server but we a…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…

920 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now