Exposing COM library on new machines. RRS feed

  • Question

  • On a development machine, I have written a COM library in C#. I have selected Register to COM interop' and I can successfully call this library from the C++ that I have written to use this library.

    At the top of the C++ library I have the following line as per examples I found online:

    #import "C:\temp\COMTest\dist\CountPath.tlb" raw_interfaces_only

    Note: the name of the library is CountPath.dll.

    Given this, everything works just find on the dev machine. Now the problem:

    I need to move the project, which is NOT an exe to another machine. The end project is another dll that it loaded by another program. I move all the libraries and tlb files involved over to the new machine for testing, and when I run the main program it crashes because it cannot find the COM library I wrote. 

    I used RegAsm on the new machine, I make the same directory structures to make sure that the tlb file and libraries were in the same place all with the same result of the program crashing.

    In the end I brought over the project for that COM library from the dev machine to the test machine, recompiled (still with 'Register for COM interop' checked) and instantly everything worked. I didn't have to move any other files, they stayed in their 'debug' folder in the project directory. If then I deleted the filed in the 'debug' folder it would crash again. Then, just to test, I moved the same files that the COM library compiles into that I originally transfered over into that debug folder and again it worked. This tells me there's probably something about how a directory is pointed to when a COM library is compiled.

    Also tried: I tried the compile trick again with 'Register for COM interop' NOT checked and it still ran with what it compiled, but I do have an AssemblyInfo.cs file that has:

    [assembly: ComVisible(true)]
    [assembly: Guid("c9b6a4d4-cc10-4ede-a6cd-beb73d4a389d")]

    So I also tried using the same csc commandline to recompile the project outside of VS2005 to see if that worked, it did not.

    Also: On my dev machine, if I delete the files out of the 'debug' folder of the library project, the main program still runs.

    The long and short of this that there seems to be something that goes on under the hood of compiling that I am unaware of, so how do I simply register the COM library on the new computer without recompiling it since that seems to be the only way I've been able to get it to work outside of the dev machine so far.

    Let me know if you need anymore info, though I've tried to say as much as I can (perhaps too much!)

    Thursday, October 2, 2008 1:14 PM


  • You probably added the COM component reference before you signed your assembly.  Simply remove the reference and add it back in so the Interop assembly gets a strong name too.
    Hans Passant.
    Thursday, October 9, 2008 9:09 PM

All replies

  • The error message you get from the client app is an important diagnostic to troubleshoot this problem.  Key ingredients are using Regasm.exe with the /codebase option to register the assembly and making sure that the assembly has all the dependencies it needs present in the probing path for the client.  Troubleshoot the former with RegEdit.exe, looking in the HKLM\Software\Classes\Clsid for the GUIDs of your COM visible classes.  Watch out for Vista UAC, you want an administrator prompt so the registration is done for all users. Troubleshoot the latter with Fuslogvw.exe.  Installing the assembly and its dependencies in the GAC is rather advisable, pretty much required to avoid COM versioning problems.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Tuesday, October 7, 2008 12:38 PM
    • Unmarked as answer by Matt warner Thursday, October 9, 2008 3:16 PM
    Friday, October 3, 2008 12:58 AM
  • Sorry for the very delayed response. I got sidetracked from this task.

    I'm attempting to use Regasm /codebase and it tells me I need a strongly typed assembly.
    So I can try to recompile giving it a strongly typed assembly but this code also uses another COM library that I do not have any access to its source code. I get the error "Referenced assembly 'Interop.OtherCOM' does not have a strong name'. I did the same using csc.exe /keyfile:mykey.snk ... with the same result

    Based on what i've seen, if I reference a 3rd party program I can't access that isn't strong key named I can't therefore reference my assembly with a strong key name. Thus it would seem I cant use the /codebase option and I am then back to square one. It's obvious there's still a way to expose this to COM interop since VS2005 does it on compile time, but I'm again at a lose for how to do this.


    Also, as a note: I'm using XP and not Vista.
    • Edited by Matt warner Thursday, October 9, 2008 3:26 PM
    Thursday, October 9, 2008 3:16 PM
  • You probably added the COM component reference before you signed your assembly.  Simply remove the reference and add it back in so the Interop assembly gets a strong name too.
    Hans Passant.
    Thursday, October 9, 2008 9:09 PM