views:

38

answers:

1

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?

A: 

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.

Hans Passant
Hello. I find difficult the possibility that this could be working by chance. The vb6 application is run from a network drive while the assemblies and the COM are copied in an arbitrary local folder. There are no copies spread in other locations. However, being the case that the TLB is generated in the same directory as the assemblies, isn't that possible that the CLR looks for the assemblies there?Interesting tool this Fuslogvw, I will try it tomorrow.Thanks!
Bernabé Panarello
I asked my client to run Fuslogvw and then to send me the log file, which you cand find here http://gist.github.com/335305. The log is identical as the one generated in my workstation.Also, the fuslog window shows the succesful bindings in both environments.
Bernabé Panarello
You didn't get the right log, this one doesn't talk about "GYF.Common.TypeBuilder". Note that your client is running his program from a mapped network drive (Q:). Which doesn't make it that likely that you can repro his exact same setup.
Hans Passant
I was looking to the log generated in my workstation and I found the problem. The (partial) search order seems to be Application Directory and then the Com's codebase directory (c:\gyf\dllnet). I called my client and verified that they had accidentally copied and older version of the GYF_Common.dll to the application's directory (one that didn't have the TypeBuilder class). I asked them to delete that file and then all worked like a charm. I couldn't have reached to this conclusion without ussing the fuslog that I didnd't know before..so I must thank you a lot for your help.
Bernabé Panarello