编译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个类，以及一些枚举和结构体。我使用C＃翻译的 Interop Forms Toolkit 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在类型信息中是相同的。唯一的区别是一行有importlib（stdole2.tlb），另一个有importlib（STDOLE2.TLB）。
 
 
 
我的机器有：Visual Studio 6.0 sp6，VB6 interop用户控制模板，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（Ver 0.1）以及OrderControlCtl（Ver 0.1）。第一个使用为程序集定义的GUID，路径显示使用RegAsm.exe生成的OrderControl.tlb。第二个在不同的机器上有不同的GUID，我的路径是C：\Program Files\Microsoft Visual Studio \VB98\vbc00305.oca，另一台机器上的路径是C：\Program Files \Microsoft Visual Studio \VB98 \mscoree.oca，在同事的计算机上是C：\windows \system32 \ mscoree.oca。两个mscoree.oca是相同的大小，但在我的机器上的vbc00305.oca是几KB小。
 
 
 
我再次看了VB6项目的引用。引用列出了OrderControl和OrderControlCtl，但只有OrderControlCtl被选中。 
 
 
 
 依赖者Walker  
 
 
 
我在DW中运行一个版本的exe在我的机器上编译的和一个编译在我们的构建机器上（我不会运行）的配置文件。他们在以下两行分歧。两者都有第一行，但是运行继续有更多的呼叫/负载，而不立即运行的那个开始分离在第一行后：
  GetProcAddress（0x7E720000 [SXS.DLL]，SxsOleAut32RedirectTypeLibrary）从OLEAUT32.DLL在地址0x7712A637处调用，并返回0x7E746129。 
从地址0x7712A637处的OLEAUT32.DLL调用的GetProcAddress（0x7E720000 [SXS.DLL]，SxsOleAut32MapConfiguredClsidToReferenceClsid），并返回0x7E745C0D。 
  
 
 
解决方案
我控制的3个特殊方法是返回（通过 ref 参数）structs。我最后使用一个解决方法涉及返回类而不是结构。但我仍然很好奇，所以我问了一个不同的问题。
 
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屋！