编译VB6应用程序瓦特/ .NET互操作的，只有上运行。如果编译我的机器上 [英] Compiling VB6 app w/ .NET interop, only runs if compiled on my machine

问题描述

我最近开发了一个.NET互操作的用户控件（Visual Studio 2008中，项目目标定位.NET 2.0）在VB6的应用程序中使用。该组件暴露1控制，1班，和几个枚举和结构。我开发它使用的互操作表格工具包2.0 项目模板这里找到。该组件具有很强的名称和被安装在GAC并与下面的脚本regasm注册的：

  @C：\\ \\gacutil.exe/ IC：\Program Files\AppName\Control.dll/ F 
 @C：\WINDOWS\Microsoft.NET\Framework\v2.0.50727\\ \\regasm.exeC：\Program Files\AppName\Control.dll/ TLB：C：\Program Files\AppName\Control.tlb
  

问题：当我编译我的机器上的VB6应用程序，它将运行任何其他机器上就好了（控制安装，当然）。然而，当应用程序在不同的机器上编译，它会在该机器上运行，但没有任何其他机器上。当我说它不跑，我的意思是你尝试运行它，绝对没有任何反应。

我以前OLEVIEW检查这两个我的机器和在控制其它机，和所有GUID是在类型信息的相同。 。唯一的区别是人有行导入库（STDOLE2.TLB）和其他有导入库（STDOLE2.TLB）

我的机器有：Visual Studio中6.0 SP6，VB6的互操作用户控制模板，Windows SDK 6.0和6.0A时，Visual Studio 2008 SP1。本机是工作的一个

同事的机器：的Visual Studio 6.0 SP6时，Visual Studio 2005

另一个机器：的Visual Studio 6.0 SP6，Visual Studio 2008中2008今早安装在此并没有纠正问题

我如何得到这些其他的机器编译VB6应用程序正确，使其运行在比它被编译的另一个机器？

（把以获取更多信息的要求在评论，我会编辑此提供。答案）

编辑：

有人建议，对涉及权限在注册的控制。我想澄清的是，控制似乎运作良好。我在工作的机器，不这样做的那些上完全相同的方式注册。该问题表现时引用该控件的VB6应用程序比我自己之外的机器上编译。

我还要补充一点，我有一个小VB6的主机应用程序，有1形式和互操作控制和几个按钮。这其中不会出现同样的问题作为主要的VB6应用程序。

可能的线索

如果任何人是熟悉使用OLEView.exe这类的，我想我可能已经发现了一个线索。当我查看类型库列表中，有OrderControl（版本0.1），以及OrderControlCtl（版本0.1）。第一个使用为集中定义的GUID和路径显示了使用RegAsm.exe生成的OrderControl.tlb。第二个有不同的GUID在不同的机器和我的路径为C：\Program Files\Microsoft视觉Studio\VB98\vbc00305.oca，在另一台机器上的路径为C：\Program Files\Microsoft视觉Studio\VB98\mscoree.oca，而同事的机器上是C：\windows\system32\mscoree.oca。这两个mscoree.oca的大小相同，但我的机器上的vbc00305.oca是几KB的。

我又在VB6项目的引用看去。引用列表都OrderControl和OrderControlCtl，但只有OrderControlCtl被选中。 OrderControl的位置是TLB文件，但OrderControlCtl的位置是OCA文件的每个站上不同。

的Dependency Walker

我跑在配置文件为DW一个版本我的机器和一个我们的构建机器（不会对矿井运行）上编上编译EXE文件的。它们发散在以下2行。都具有第一行中，但是在运行之一仍然与更多的呼叫/负载，而没有立即运行所述一个开始的第一行这里经过分离：

  GetProcAddress的（0x7E720000 [SXS.DLL]SxsOleAut32RedirectTypeLibrary）从OLEAUT32.DLL地址0x7712A637打电话回来0x7E746129。 
 GetProcAddress的（0x7E720000 [SXS.DLL]SxsOleAut32MapConfiguredClsidToReferenceClsid）从OLEAUT32.DLL之称的地址0x7712A637并返回0x7E745C0D。 
  

解决方案

我因为发现它不得不做在我的控制3特定的方法是'回归'（通过 REF 参数）结构。我结束了使用涉及返回类的结构，而不是一种解决方法。但我还是好奇，所以我问了不同的问题

I recently developed an interop user control in .NET (Visual Studio 2008, project targetting .NET 2.0) to be used in a VB6 application. The assembly exposes 1 control, 1 class, and a few enums and structs. I developed it using C# translations of the Interop Forms Toolkit 2.0 project template found here. The assembly has a strong name and gets installed in the GAC and registered with regasm with the following script:

@"C:\gacutil.exe" /i "C:\Program Files\AppName\Control.dll" /f
@"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe" "C:\Program Files\AppName\Control.dll" /tlb:"C:\Program Files\AppName\Control.tlb"

The Problem: When I compile the VB6 app on my machine, it will run just fine on any other machine (control installed, of course). However, when the app is compiled on a different machine, it will run on that machine, but not on any other machine. And when I say it doesn't run, I mean you try to run it and absolutely nothing happens.

I used OleView to examine the control on both my machine and the other machine, and all GUIDs are the same in the type information. The only difference was one had the line importlib("stdole2.tlb") and the other had importlib("STDOLE2.TLB").

My machine has: Visual Studio 6.0 sp6, VB6 interop user control templates, Windows SDK 6.0 and 6.0A, Visual Studio 2008 sp1. This machine is the one that works.

Coworkers machine: Visual Studio 6.0 sp6, Visual Studio 2005

Another machine: Visual Studio 6.0 sp6, Visual Studio 2008. 2008 was installed on this this morning and did not rectify the problem.

How do I get these other machines to compile the VB6 app correctly so that it runs on machines other than the one on which it was compiled?

(Put requests for more information in comments and I'll edit this to provide answers.)

Edits:

A suggestion was made regarding permissions in relation to registering the control. I'd like to clarify that the control seems to work well. I register it in the exact same way on the machine that works and the ones that don't. The problem manifests itself when the VB6 app that references the control is compiled on a machine other than my own.

I should also add that I had a small VB6 host app that had 1 form and the interop control and a couple buttons. This one does not exhibit the same problem as the main VB6 app.

Possibly a clue

If anybody is familiar with using OleView.exe, I think I may have discovered a clue. When I view the Type Libraries list, there is "OrderControl (Ver 0.1)" as well as "OrderControlCtl (Ver 0.1)". The first uses the GUID defined for the assembly and the path shows the OrderControl.tlb generated from using RegAsm.exe. The second has different GUIDs on the different machines and the path on mine is "C:\Program Files\Microsoft Visual Studio\VB98\vbc00305.oca", the path on the other machine is "C:\Program Files\Microsoft Visual Studio\VB98\mscoree.oca", and on the coworker's machine is "C:\windows\system32\mscoree.oca". Both mscoree.oca are the same size, but the vbc00305.oca on my machine is several KB smaller.

I looked again at the VB6 project's references. The references list both OrderControl and OrderControlCtl, but only OrderControlCtl is checked. OrderControl's location is the TLB file, but OrderControlCtl's location is the OCA file that's different on each station.

Dependency Walker

I ran profiles in DW for a version of the exe compiled on my machine and one compiled on our build machine (which won't run on mine). They diverge at the following 2 lines. Both have the first line, but the one that runs continues on with more calls/loads, while the one that does not run immediately begins detaching after the first line here:

GetProcAddress(0x7E720000 [SXS.DLL], "SxsOleAut32RedirectTypeLibrary") called from "OLEAUT32.DLL" at address 0x7712A637 and returned 0x7E746129.
GetProcAddress(0x7E720000 [SXS.DLL], "SxsOleAut32MapConfiguredClsidToReferenceClsid") called from "OLEAUT32.DLL" at address 0x7712A637 and returned 0x7E745C0D.

解决方案

I've since discovered that it had to do with 3 particular methods on my control that were 'returning' (via ref parameter) structs. I ended up using a workaround involving returning classes instead of structs. But I'm still curious, so I asked a different question.

这篇关于编译VB6应用程序瓦特/ .NET互操作的，只有上运行。如果编译我的机器上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！