none
My own custom dll generates "ActiveX component can't create object" RRS feed

  • Question

  • I created a com dll for use in Access. I wrote it in vb.net in VS 2012. It does some email work. It's actually quite simple. It works perfectly on my development machine but not on one of my client's machines.

    Both of our machines are running Windows 7 64 bit. Both of our machines are running Access 32 bit (his is Access 2016 and mine is Access 2010).

    The dll is set to "any CPU".

    Registering the dll using RegAsm works as expected. It says it's successful.

    In the Access.mdb I created to test this, everything appears to be fine in references. Nothing is "missing". In fact, the dll I created shows up as expected when I choose the tlb file and reference it. In my code, intellisense works fine too. And it compiles without errors.

    the "dim" line runs just fine but the "set" line generates the "ActiveX component can't create object" error.

    Dim oEmailClass As myCustomEmailer.SendEmailClass
    Set oEmailClass = New myCustomEmailer.SendEmailClass

    I've hunted around for a cause and can't find anything that gets me anywhere. The folder containing the mdb and the dll has full permission for his user.

    Thanks in advance,

    Keith


    • Edited by keithrh Monday, April 18, 2016 2:51 PM
    Monday, April 18, 2016 2:38 PM

Answers

  • Ok, so I would try a repair of 4.5 from the control panel (programs and features - right click on .net 4.5 and repair).

    If above does not fix, then try the .net repair tool here:

    https://www.microsoft.com/en-us/download/details.aspx?id=30135

    As noted the instant you correctly choose x86, we see that the bit size and building the application to the correct x86 shows that your build is not correct.

    I would also ensure during testing that you use re-build project as opposed to just build – (re-build is same as clean + build project – the “clean” or re-build option deletes all .dll’s in the target bin folder will be removed.

    MAKE SURE you now grab the resulting .dll's from the x86 folder and NOT the regular bin folder you been using.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Tuesday, April 19, 2016 8:31 PM

All replies

  • Just a guess, but check to see if your client has the same .NET framework installed.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Monday, April 18, 2016 3:22 PM
  • Good point. I thought it was, based on the matching path information to RegAsm (C:\Windows\Microsoft.NET\Framework\v4.0.30319\) and the fact that my dll registered fine on his machine, but I'll check his registry when I'm able to reach him to be sure. I'm on 4.5.50709 and it's possible he's still on 4.0
    Monday, April 18, 2016 4:07 PM
  • Nope. That wasn't it. Good suggestion though. Thanks. He's running the same exact version I am.
    Monday, April 18, 2016 4:41 PM
  • You might have another conflicting DLL. If you are referencing a library with a different version number from what he has it could cause a reg key problem. Might be something to check.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Monday, April 18, 2016 7:49 PM
  • Don’t use “any” CPU. Force the project to x86.

    And if .net 4.5 is not required, then compile to 4.0

    It also possible that the target machine has some additional issues. For example, when running regasm on the target machine, you need to run as administrator in most cases – in fact quite sure you don’t see an error message, but it often will not work unless regasm is run as an admin.

    I would also consider using late binding, and CreateObject("your custom objet") as opposed to New your object.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    kallal@msn.com

    Monday, April 18, 2016 8:57 PM
  • Hi keithrh,

    there is some common reasons to get this error ActiveX component can't create object" error.

    please visit the link below that may be help you to solve your issue.

    ActiveX component can't create object

    Regards

    Deepak


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, April 19, 2016 9:24 AM
    Moderator
  • Was the first thing I went through Deepak. Thanks though.
    Tuesday, April 19, 2016 1:12 PM
  • Bill,

    You mean if the names are the same? No. Not a chance. My dll has my company name in it. I knew that could be a problem going in so I planned ahead. Thanks though. :)

    Tuesday, April 19, 2016 1:23 PM
  • On the failing computer, what does Event Viewer say?

    Best regards, George

    Tuesday, April 19, 2016 2:32 PM
  • You need to address the issues I outlined.

    I been deploying .net dll’s for years to be used with Access.

    Again:

    Force the project to x86, and copy the .dll from the x86 bin folder. You cannot have the system “guess” which bit size to use, and if you don’t force this issue, you will enjoy a nice long hot summer of drinking lemonade while you chase down reasons for x32 MS access not finding a registered x32 .dll/object.

    Hint: you cannot have the object registered for both x32 and x64 at the same time. If you don’t force this issue, then you on a wild goose chase.

    Next again:

    On target machines, you have to run regasm with admin rights, and if you don’t, it will often fail.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Tuesday, April 19, 2016 4:15 PM
  • On my system, when I change my dll's settings to .net 4 (from 4.5) and CPU=x86, I get the "RegAsm.exe is not a valid Win32 application" error. And when I just double click RegAsm (the 32 bit one) I get the same error. I found something online regarding this that said to reinstall 4.0 but I can't do that since 4.5 is installed. And there's no option to repair 4.0 when doing so.

    Tuesday, April 19, 2016 8:07 PM
  • Ok, so I would try a repair of 4.5 from the control panel (programs and features - right click on .net 4.5 and repair).

    If above does not fix, then try the .net repair tool here:

    https://www.microsoft.com/en-us/download/details.aspx?id=30135

    As noted the instant you correctly choose x86, we see that the bit size and building the application to the correct x86 shows that your build is not correct.

    I would also ensure during testing that you use re-build project as opposed to just build – (re-build is same as clean + build project – the “clean” or re-build option deletes all .dll’s in the target bin folder will be removed.

    MAKE SURE you now grab the resulting .dll's from the x86 folder and NOT the regular bin folder you been using.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Tuesday, April 19, 2016 8:31 PM
  • The repair on my system worked. That enabled me to compile, register and use the x86 .net 4.0 version in my mdb. Thanks for that advice.

    I know the RegAsm.exe in the 32 bit framework folder on my client's machine is not corrupt (reasonably sure) because I walked him through double clicking it from explorer today and it didn't generate the error. Going to try my new dll on his system tomorrow. Fairly confident it will work this time. We'll see.

    Always do clean builds of everything. Got in that habit a long time ago.

    And what x86 folder are you talking about? There is no such animal in my project's folder structure. Just the one bin folder.

    Thanks for the info everyone.

    Wednesday, April 20, 2016 2:09 AM
  • Yes, if you look inside of the bin folder, you see a x86 folder. It is FROM THAT folder you want to grab the debug or release version of your dll.

    Here is a screen shot : note the x86 folder is a SUB FOLDER inside of the bin folder is created when you build a x86 project:

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Saturday, April 23, 2016 9:02 PM