VBA call to VB 2005 DLL (COM) fails

Hi,

I have to call a DLL (COM in VS 2005 lingo) from inside Excel 2000 (VBA code). When I compile the DLL on .NET Framework 1 it works fine. However, when I compile the DLL in .NET 2 I run into a "File or assembly name <dll name> or one of its dependencies was not found"

Please help if you can.

Thanks much

Visual Basic8

Don't know if Excel has the same issue, but I had problems calling a component from Word when moving from VS 2003 -> VS 2005.

I had to create a config file for Word (Winword.exe.config) and tell it which version of the framework to use:

Maybe Excel requires something similar

DeborahK,

Thanks for the quick reply. I actually found the answer on another thread which I have pasted below by "Tarp". I had the same issue when moving from VS 2003 to VS 2005. You could use your fix, or the MS fix mentioned in the kb article 908002 will fix all your previous and future DLLs.

http://download.microsoft.com/download/b/6/7/b6711d3b-b509-4567-8599-98bf3473310f/vs2005-kb908002-enu-x86.exe

-----------------------------------------------------------------------------------------------------------------

The problem was not in my code but there is/was a error in the 2.0 framework.
A fix was released 2005-12-02 and it works:
http://support.microsoft.com/default.aspx/kb/908002

Hi,

I had the same problem.

So I installed the fix which solves the problem on my machine. (the machine where VS2005 is installed and where the dll is compiled).

Now I tried to export on an other machine where VS2005 is not installed. Bang, same problem again.

So I suppose that the problem is somewhere with excel and not within the dll.

Anybody has an idea

Dogleg,

You are correct. It works fine on any machine wich has Visual Studio 2005 installed. It fails on machines that do not have 2005 installed.

I am at the moment trying to install my DLL on a non VS2005 machine. I even ran the KB908002's two .msi files and the .exe file on the machine I want to deploy on. It did install both the Shared Add-in extensibility and support updates to the client machine. I can confirm this from Control Panel.

I suppose the issue could be the way in which the DLL is registered, since the machine where I compile it registers it for interop automatically, yet I have to use "regasm" on any client machines I install the DLL to.

The Excel on my development machine has no problem linking to the DLL, only the Excels on the client machines have a problem.

I will keep working on this. Please let me know if you find anything along these lines

Thanks

Dogleg,

I finally found the answer. I will paste the answer posted by another MSDN user. User by the name of "Blackwood" posted the below answer. I don't know how best to link it, so I copied the text. Basically, what must be done is use the patch (KB908002) and deploy it with another application to the target client machine. Then follow the instructions below to deploy the DLL to the client machine. The only different thing I did from Blackwood is that I copied the created .snk file also to the location where I deploy the DLLs on the client machine.

=====================================================================

Thanks very much for your help. That did it.

To summarise, this is what I did to be able to use my class library in Excel 2003 VBA

On the References tab of the class library's Properties page, I checked "System.Runtime.InteropServices" in the Imported Namespaces list.
I added the <ComVisible(True)><ComClass()> attributes to each Public Class definition
On the Signing tab of the class library's Properties page, I checked Sign the Assembly and used the Choose a Strong Name Key File box to create a new key file.
After building the solution, I opened a Command Prompt box and:
- Changed the current directory to the \Bin\Release folder of my project directory
- Entered "c:\windows\microsoft.net\framework\v2.0.50727\regasm" TestClassLibrary1.dll /tlb /codebase

This has been quite a learning experience.

======================================================================

apparently, the only difference to what I did is using the regasm from the version 2.0.50727

"c:\windows\microsoft.net\framework\v2.0.50727\regasm" TestClassLibrary1.dll /tlb /codebase

I've probably used the old one.

In the mean time I found an other solution: enforcing excel to use the 2.0.50727 framwork by writing an excel.exe.config file...

Glad it worked for you. If you get a chance, I would like to get detailed instructions on how to force excel to use a different framework. I heard about this, but I have not seen how to implement this. I would like to keep this info for future use.

Thanks

My winword.exe.config file contents are earlier in this thread. I am assuming that the execl.exe.config file contents would be the same.

Just create a config file, add the code shown earlier in this thread to the config file, and put the config file in the same directory that you have Excel.exe.

That should be all of the instructions...