将com暴露的程序集部署到客户端时遇到以下问题。 COM组件应该由vb6应用程序完成。这是它的完成方式
1）我有一个c＃项目，其中有一个类暴露给COM的几个方法
2）项目引用了多个程序集
3）我编译项目，生成一个包含程序集和所有引用的dll的文件夹（名为dllcom）
4）我在文件夹中包含了一个.bat，它执行以下操作：
regasm /u c:\dllcom\LibInsertador.dll
del LibInsertador.tlb
regasm c:\dllcom\LibInsertador.dll /tlb:c:\dllcom\LibInsertador.tlb /codebase c:\dllcom\
pause
5）在我实验室的许多工作站本地运行蝙蝠之后，我能够毫无问题地从我的vb6应用程序中使用生成的tlb。我甚至只能通过运行这个bat来更新dll，而无需重新编译vb6应用程序。我的意思是我没有vb6 fiding和调用暴露的com对象的问题。
6）我将SAME FOLDER发送给我的客户
7）他们在本地执行.bat，没有任何错误
8）他们执行vb6应用程序，vb6找到主程序集，.net代码似乎正确运行（它甚至能够生成日志文件），直到它必须实例化它的第一个引用程序集。然后，他们得到以下例外：
“无法从程序集'GYF_Common，Version = 1.0.0.0，Culture = neutral，PublicKeyToken = null'加载类型'GYF.Common.TypeBuilder'。”
其中“GYF.Common”是LibInsertador引用的程序集，TypeBuilder是GYF.Common中包含的类。 GYF.Common不是已签名的程序集，它不在GAC中，只与Libinsertador位于同一文件夹中。根据.net反射器，版本是正确的。
¿关于可能发生的事情的任何想法？
答案 0 :(得分：0)
这仅适用于您的机器。对于任何依赖项，CLR没有理由查看带有COM可见DLL的目录。它将探测EXE文件夹和GAC以查找它们。
不确定此事故是如何在您的计算机上发生的，请使用Fuslogvw.exe查看程序集解析。也许您的测试程序与COM程序集位于同一文件夹中？执行此操作的正确方法是将程序集部署到GAC（无/代码库）。重要的是要避免被DLL地狱问题活着吃掉，这个问题总是潜伏在COM附近。