Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 806
  • Last Modified:

430 Class does not support Automation with custom ActiveX DLL

Hi,
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....
0
jmerritt
Asked:
jmerritt
  • 3
  • 2
1 Solution
 
SRigneyCommented:
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).
0
 
jmerrittAuthor Commented:
Hi,
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!


0
 
SRigneyCommented:
'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.
0
 
jmerrittAuthor Commented:
Awesome!

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

Thanks for giving me somebody to lean on...
0
 
SRigneyCommented:
You're welcome.  I just come here and do this because I like the gratification I get helping others.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now