Answered by:
Register VS 2013 C# DLL on Laptop for COM access in Excel VBA using using RegAsm

Question
-
I have created a DLL in VS2013 on my Desktop computer. I have enabled it for COM access in VS2013 Project tab properties sheet by checking both the "Make assembly COM-visible" and "Register for COM Interop" check boxes. Using Excel VBA on my desktop, I am able to add the reference via the tlb file. and successfully use the DLL methods in my VBA code.
I would like to port the dll to my Laptop, where VS is not installed, and register it using RegAsm. I have moved the files to a sub-directory of the desktop of my lap top and used RegAsm to register it with the below command line. The registration completes with successful registration being indicated. And a new local tbl file being created. But the dll can't be accessed from Excel. Using regedit to compare the registrations on both my desktop and laptop, it is clear that the registrations are not the same.
Can someone please provide info on how to correctly register the DLL with RegAsm (or appropriate tool)?
Thanks you.
RegAsm Command
C:>(path to)\RegAsm (path to)MyDLL.dll /basecode /tlp:MyDLL.tbl
Jim Gunn
Wednesday, December 6, 2017 3:41 AM
Answers
-
I was finally able to successfully register my app on my Laptop.
My DLL is a C# any cpu dll created in VS2013. I had been using the RegAsm app in the Framework64 directory, which apparently is intended for 64bit apps. I used the RegAsm app in the Framework (for 32 bit apps on a 64bit cpu) directory and registration was successful.
Also I did not have a clear understanding of the /codebase option of RegAsm. Apparently this option must be used when the dll is not in the standard window DLL directory. My dll is in a sub-directory on my desktop.
Although now working, this work raised another question. Can I get the dll to register as a 64bit dll for improved performance? My Office/Excel is Office 2010, 32 bit. It would be useful to be able to access higher performance dlls in my Excel VBA code.
Thank you.
Jim Gunn
- Proposed as answer by Wendy ZangMicrosoft contingent staff Monday, December 11, 2017 12:49 AM
- Marked as answer by JimGDal Wednesday, December 13, 2017 10:51 PM
Wednesday, December 6, 2017 9:51 PM -
Regasm uses the codebase option to create and associate the DLL COM CLSID references in the Windows Registry with a file path to the assembly. Without it, you would need to register the assembly with the GAC (Global Assembly Cache) so that any app that references the DLL can find it.
You may also be able to use registration-free COM if the assembly is located in the same folder as the app, but I would recommend against it unless you have a configuration or policies where it is the only option.
Regarding your 64-bit question, you can't load a 64-bit DLL into a 32-bit process, so this would not work for your 32-bit version of Excel.
Paul ~~~~ Microsoft MVP (Visual Basic)
- Marked as answer by JimGDal Wednesday, December 13, 2017 10:51 PM
Wednesday, December 13, 2017 4:49 PM
All replies
-
I was finally able to successfully register my app on my Laptop.
My DLL is a C# any cpu dll created in VS2013. I had been using the RegAsm app in the Framework64 directory, which apparently is intended for 64bit apps. I used the RegAsm app in the Framework (for 32 bit apps on a 64bit cpu) directory and registration was successful.
Also I did not have a clear understanding of the /codebase option of RegAsm. Apparently this option must be used when the dll is not in the standard window DLL directory. My dll is in a sub-directory on my desktop.
Although now working, this work raised another question. Can I get the dll to register as a 64bit dll for improved performance? My Office/Excel is Office 2010, 32 bit. It would be useful to be able to access higher performance dlls in my Excel VBA code.
Thank you.
Jim Gunn
- Proposed as answer by Wendy ZangMicrosoft contingent staff Monday, December 11, 2017 12:49 AM
- Marked as answer by JimGDal Wednesday, December 13, 2017 10:51 PM
Wednesday, December 6, 2017 9:51 PM -
Hi JimGDal,
Thanks for your sharing.
Please mark the solution as answer to close the thread. This will make answer searching easier in the forum and be beneficial to community members.
Best Regards,
Wendy
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.Wednesday, December 13, 2017 7:06 AM -
Regasm uses the codebase option to create and associate the DLL COM CLSID references in the Windows Registry with a file path to the assembly. Without it, you would need to register the assembly with the GAC (Global Assembly Cache) so that any app that references the DLL can find it.
You may also be able to use registration-free COM if the assembly is located in the same folder as the app, but I would recommend against it unless you have a configuration or policies where it is the only option.
Regarding your 64-bit question, you can't load a 64-bit DLL into a 32-bit process, so this would not work for your 32-bit version of Excel.
Paul ~~~~ Microsoft MVP (Visual Basic)
- Marked as answer by JimGDal Wednesday, December 13, 2017 10:51 PM
Wednesday, December 13, 2017 4:49 PM -
Thank you for your reply.
I tried registration-free DLLs and was often successful in getting initial features to work. But as I added features, some would not work. I could not figure out which would work or not, other than trial and error. And I could not fix non-working features. So I registered and don't have this problem. If you have suggestions here, they will be appreciated.
My DLL work is essentially for personal use only. Occasionally, shared with reliable associates. And the dll is always in the same directory as the app. My goal is improved performance. And I am finding that C# DLL code improves supported VBA code with better VBA structure and less clutter.
Jim Gunn
Wednesday, December 13, 2017 11:07 PM