Home/ Questions/Q 694067
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T02:49:07+00:00

I am facing the following issue when deploying a com-exposed assembly to my client’s.

  • 0

I am facing the following issue when deploying a com-exposed assembly to my client’s. The COM component should be consummed by a vb6 application. Here’s how it’s done

1) I have one c# project which has a class with a couple of methods exposed to COM

2) The project has references to multiple assemblies

3) I compile the project, generating a folder (named dllcom) that contains the assembly plus all the referenced dlls

4) I include in the folder a .bat which does the following:

regasm /u c:\dllcom\LibInsertador.dll
del LibInsertador.tlb
regasm c:\dllcom\LibInsertador.dll /tlb:c:\dllcom\LibInsertador.tlb /codebase c:\dllcom\
pause

5) After running the bat locally in many workstations of my laboratory, i’m able to consume the generated tlb from my vb6 application without any problems. I’m even able to update the dll by only means of running this bat, without having to recompile the vb6 application. I mean that im not having issues of vb6 fiding and invoking the exposed com object.

The problem

6) I send the SAME FOLDER to my client

7) They execute the .bat locally, without any errors

8) They execute the vb6 application, vb6 finds the main assembly, the .net code seems to run correctly (it’s even able to generate a log file) until it has to intantiate it’s first referenced assembly. Then, they get the following exception:

“Could not load type ‘GYF.Common.TypeBuilder’ from assembly ‘GYF_Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.”

Where “GYF.Common” is an assembly referenced by LibInsertador and TypeBuilder is a class contained in GYF.Common. GYF.Common is not a signed assembly and it’s not in the GAC, just in the same folder with Libinsertador. According to .net reflector, the version is correct.

¿Any ideas about what could be happening?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This only works by accident on your machine. The CLR has no reason to look inside the directory with your COM visible DLL for any dependencies. It will probe the EXE folder and the GAC to look for them.

    Not sure how this accident happens on your machine, take a look at the assembly resolution with Fuslogvw.exe. Maybe your test program is in the same folder as your COM assembly? The proper way to do this is to deploy the assemblies to the GAC (no /codebase). Important to avoid getting eaten alive by the DLL Hell problem that always lurks around the corner with COM.

    • 0