I recently developed a custom interop control in .NET (Visual Studio 2008, the .NET 2.0 target project) that will be used in the VB6 application. The assembly provides 1 control, 1 class, and several enumerations and structures. I developed it using C # translations Interop Forms Toolkit 2.0 project template found here . The node has a strong name and is installed in the GAC and registered in 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"
Problem:. When I compile the VB6 application on my machine, it will work fine on any other computer (of course, the controls are installed). However, when the application is compiled on another machine, it will work on that computer, but not on any other machine. And when I say that this does not work, I mean that you are trying to run it, and absolutely nothing happens.
I used OleView to check the control both on my computer and on another computer, and all GUIDs are the same in the type information. The only difference was that the line had 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 car is working.
Collection 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 fix the problem.
How do I get these other machines to correctly compile the VB6 application so that it runs on machines other than those on which it was compiled?
(Put requests for more information in the comments, and I will edit this to provide answers.)
edits:
A suggestion was made regarding permissions regarding the registration of a control. I would like to clarify that control seems to work well. I register it in the same way on a machine that works, and those that do not. The problem occurs when the VB6 application that references the control is compiled on a machine other than mine.
I should also add that I had a small VB6 host application that had 1 form, as well as interop controls and pair buttons. This does not have the same problem as the main VB6 application.
Maybe the key
If someone is familiar with using OleView.exe, I think I might have discovered the key. When I look at the list of sample libraries, 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 OrderControl.tlb generated using RegAsm.exe. The second one has different GUIDs on different machines, and the path on mine is "C: \ Program Files \ Microsoft Visual Studio \ VB98 \ vbc00305.oca", the path on another computer: "C: \ Program Files \ Microsoft Visual Studio \ VB98 \ mscoree .oca ", and on the computer -" C: \ windows \ system32 \ mscoree.oca ". Both mscoree.oca are the same size, but vbc00305.oca on my machine is few kilobytes less.
I again looked at the links to the VB6 project. The list of links is OrderControl and OrderControlCtl, but only OrderControlCtl. The OrderControl location is a TLB file, but the OrderControlCtl location is an OCA file that is different at each station.
Dependency evasion
I ran profiles in DW for the exe version compiled on my machine, and one compiled on our build machine (which will not work on mine). They diverge in the following two lines. Both have the first line, but the one that works continues with a lot of calls / loads, and the one that does not start immediately starts disconnecting 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.