none
Run-time error 430 - Class does not support Automation or does not support expected interface PLEASE HELP!!

    Question

  • Hello Folks,

    I'm getting a bit desperate here.

    I am calling a .Net .dll that I wrote using VBA in Access. This worked without any problems. I made some changes to the C# code and re-compiled. Now when I try to run the code in Access I get 'Run-time error '430' - Class does not support Automation or does not support expected interface'. I reverted back to the previous code and I am still having the same problem. Code compiles fun and I can run everything in C# without any problems.

    I have absolutely no clue what this means!!??

    This happened before a while back. So I re-wrote the .dll, recompiled and re-added as a reference. It worked great up until now.

    ANY IDEAS???!?!? Pretty much freaking out here now.

    Cheers,

    Rick

    Monday, June 08, 2009 7:31 PM

Answers

  • Well, it's taken a lot of trial and error, but I think I've finally figured out the problem.

    Most of the problem has to do with my unfamiliarity with .NET at a system-wide level. Here's the scenario:

    I have a .dll authored in C#. I want to use this DLL in an Access VBA application I have written. There are interface questions that had to be addressed which I will not get into here as it has a minimal impact with regards to this thread. This .dll needs to be distributed to multiple desktops. I was hoping I could publish the .dll to the network and simply have everyone point to that common folder.

    It appears that I am not able to use a .dll across the network like that. Could be a network security issue or it may be some other reason. So, I decided to create a local folder that everyone would have on their system. I published to that folder on the development system. Imported the reference in VBA. Everything worked great.

    I then copied all the resource created when published to another machine, and it did not work. In fact, it is not possible to add the reference in Access VBA even though a type library file is available and it looks like you can select it. The assembly needs to be registered in the GAC on every workstation. To make that work, use regasm on that machine using the type library option:

    regasm [assembly.dll] /tlb:[assembly.tlb]

    I won't profess to know what happens when assemblies are registered. I assume they get an entry in the Registry with the corresponding GUID.

    To see more about my questions on the interface: http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/7fa723e4-f884-41dd-9405-1f68afc72597
    • Marked as answer by rbeddoe Monday, June 22, 2009 2:52 PM
    Monday, June 22, 2009 2:52 PM

All replies

  • After you recompiled, did you reset the reference in your VBA code?
    www.insteptech.com
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Monday, June 08, 2009 7:49 PM
  • yes.

    So just to be sure I wasn't going insane, I created another class and compiled a new .dll with a new name. Imported that one and it is working fine.

    Problem is, this is the THIRD time I've had to do this. The first two times I thought maybe it was dimentia setting in, but now I'm sure it's the software going crazy, not me.

    I'll have to watch closely to see if it happens again. One of the problems, I think, is that I'm not all that sure about the 'Interface' I need in order to expose
    this to COM.

    Here's what I have:

    [

    ClassInterface(ClassInterfaceType.AutoDispatch)]

    There are 3 objects in the ClassInterfaceType object: AutoDispatch, AutoDual, and none.

    You can see here that I'm using AutoDispatch. The problem there is that my objects are not exposed to intellisense. If I use AutoDual, that will work, but it's not recommended.

    Rick


    Tuesday, June 09, 2009 8:39 PM
  • Well, it's taken a lot of trial and error, but I think I've finally figured out the problem.

    Most of the problem has to do with my unfamiliarity with .NET at a system-wide level. Here's the scenario:

    I have a .dll authored in C#. I want to use this DLL in an Access VBA application I have written. There are interface questions that had to be addressed which I will not get into here as it has a minimal impact with regards to this thread. This .dll needs to be distributed to multiple desktops. I was hoping I could publish the .dll to the network and simply have everyone point to that common folder.

    It appears that I am not able to use a .dll across the network like that. Could be a network security issue or it may be some other reason. So, I decided to create a local folder that everyone would have on their system. I published to that folder on the development system. Imported the reference in VBA. Everything worked great.

    I then copied all the resource created when published to another machine, and it did not work. In fact, it is not possible to add the reference in Access VBA even though a type library file is available and it looks like you can select it. The assembly needs to be registered in the GAC on every workstation. To make that work, use regasm on that machine using the type library option:

    regasm [assembly.dll] /tlb:[assembly.tlb]

    I won't profess to know what happens when assemblies are registered. I assume they get an entry in the Registry with the corresponding GUID.

    To see more about my questions on the interface: http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/7fa723e4-f884-41dd-9405-1f68afc72597
    • Marked as answer by rbeddoe Monday, June 22, 2009 2:52 PM
    Monday, June 22, 2009 2:52 PM