regasm requires asmpath to find framework dlls on some PCs

Question

I have a C# library that is COM visible.  On my local development box it works properly and I can call it from Excel when I check the build option to register for COM interop.  If I disable the registration and register it manually with:

    regasm mylibrary.dll /codebase / /tlb:mylibrary.tlb

then the library is accessible from Excel on my local box or on any box that has VS2008 installed (or there could be some other difference I am not aware of).

If I take the same files to a PC that is the same COE build, but doesn't have VS2008 (and possibly other unknown differences) then after registering with the same commandline I get an error that mylibrary.dll or one of its dependencies could not be found.  Using ProcMon to watch what is happening, a coworker determined that the dependencies that were breaking are standard framework assemblies, such as System.dll.  By adding asmpath options for each and every required framework dll, the registration works and Excel can use the library.

Why would I need an asmpath to find standard framework dlls?  And what is different on machines with VS2008 that I don't need the asmpath option?

Any ideas?

Regards,

Dale

Answer 1

Hello, Dale
The reason for you don't need the asmpath option you could success is that if you have visual studio 2008 installed, the assembly your referenced are automatically installed in the GAC. So you don't need to add the /asmpath manually.
If I misundertood you, feel free to let me know.
Thanks
Chao

Answer 2

But the assemblies not found without the asmpath are standard .Net framework assemblies, such as system.dll.  Those are in the GAC with or without VS2008.

Getting this COM library registered so it can be called from Excel on a non-developer machine is eating my lunch right now.  I've been working on this single issue for over a week.  I want to try installing the component in the GAC to see if that resolves the "file not found" error with the COM library in the same place as the .Net framework DLLs.  But that isn't working either; I get  the same error.  Excel VBA requires that we set the reference to the TLB, not the DLL so I can't find the library in the GAC.

Answer 3

Hello, Dale

When we install visual studio 2008 it will add some path to the command Prompt. Type the set path command, if you open your command prompt, then type "set path", it will show something like:

Path=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;C:\Windows\Microsoft.NET\Framework\v3.5;C:\Windows\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\PROGRA~1\CA\SHARED~1\SCANEN~1;c:\Program Files\CA\eTrust Antivirus;C:\Program Files\Windows Imaging\;C:\Program Files\Common Files\Thunder Network\KanKan\Codecs;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\System Center Operations Manager 2007\;C:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Tools\Sandcastle\ProductionTools\;C:\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Tools\Sandcastle\ProductionTools\;C:\Windows\Microsoft.NET\Framework\v3.5
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

This is the path to search when the command need to find the files it needed. So you don't need to use /asmpath manually, when he search in  C:\Windows\Microsoft.NET\Framework\v2.0.50727 folder, he may find the System.dll. So it execute successfully.

I think that's the main reason to make the difference.

If you have any doubt, feel free to let me know.

Thanks

Chao

Answer 4

Chao,

Thank you.  I will check this tomorrow and let you know.

Regards,

Dale

Answer 5

Hello, Dale
I have done many experiment to prove this.
Thanks
Chao