开发者

VB6 App + .Net component working as compiled app but not in VB6 IDE

开发者 https://www.devze.com 2022-12-30 11:07 出处:网络
I have a VB6 App that uses a .Net component (via a .tlb reference in the VB6 app) which is working fine when executed as a compiled app, but it produces an error from the VB6 IDE a certain point when

I have a VB6 App that uses a .Net component (via a .tlb reference in the VB6 app) which is working fine when executed as a compiled app, but it produces an error from the VB6 IDE a certain point when it is trying to use the .NET component.

I should note that the error occurs when the .NET component is meant to be invoking a third party reporting component. The error is specific to the reporting component. Something about not being able to cast from String to some other type.

The .tlb is in the same location as the application executable so I don't why there should be a problem. There 开发者_如何学JAVAis a .config for one of the DLLs but it only specifies where the log file should be.

I need to have the application running in the IDE in order to debug and step through the code. What could the problem be? Could the VB6 IDE be looking in a different location for certain DLLs?


This could be due to a runtime version mismatch. Try the following:

Create a .config file for the IDE (e.g. the EXE name of the IDE executable + .config).

Paste the following in it:

<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727"/>
    <requiredRuntime version="v2.0.50727" safemode="true"/>
  </startup>
</configuration>

This will ensure that the .NET 2 runtime is loaded, no matter in which order .NET COM components are activated (some of which may be loaded by the IDE, causing a runtime mismatch in the process).


A casting exception isn't easily explained by a problem with the default directory of a program. Which is about all that ought to be different when you run your app from the VB6 IDE rather than directly.

You'll have to use a debugger to find out what's going wrong. Luckily that's easy when you use VB6. Start by opening your .NET project in Visual Studio. Project + Properties, Debug tab. Select "Start external program", click the button with the dots and navigate to vb6.exe. It should be located in c:\program files\microsoft visual studio\vb98\vb6.exe if you used the default install options.

You can set the "Command line options" setting to the path to your .vbp project so the IDE automatically loads it. Not strictly necessary.

Debug + Exceptions, check the "Common Language Runtime Exception" Thrown check box. Press F5 to start the debugger. The VB6 IDE will now open, load your VB6 project if necessary. Run the project and recreate the failure case. That should cause a breakpoint in the Visual Studio debugger. You may have to switch to it by hand, the taskbar button should be blinking. Use the normal debugging tools to find out why the exception was thrown.

Note that you can also set breakpoints in Visual Studio, useful if you need to single-step through the code to find out what's wrong. When you press F5, the breakpoint indicator turns hollow since the DLL isn't loaded yet. As soon as your VB6 project creates a class object from your .NET code, the DLL will be loaded (visible in the Output window) and the breakpoint indicator will turn solid. If that doesn't happen then you may need to run Regasm.exe with the /codebase option so that the DLL in the project's bin\Debug folder gets registered as the COM server.


Like Lucero, I wonder about the config file... I recently had an interop scenario where I had to create a config file for the vb6 executable in order to get the .net dll to read the settings properly within the appdomain in which the .net library runs. In that case, I was able to take the existing config for the dll and copy it as vb6.exe.config where vb6 is the name of your vb6 executable.

If this thought is in the right direction, I'd agree with Lucero that your *.exe.config file needs to be associated with the origination executable file for the IDE... which I believe is vb6.exe.

Although the vb6 executable itself does not require a .config file to work, the existence of a config file will affect any .net components that get loaded, so it could make a difference.

You could rule out the config file by temporarily hard coding your settings. If that works in the VB6 IDE, then you know you're heading in the right direction.


Mike L has said this but my answer here describes all the issues regarding VB6 and exe.config files, and I believe that is the problem here.


I would try to register the .net component using regasm with the /codebase switch. The tool will give you a warning if the assembly is not in the GAC, but you can ignore that warning unless you have several different versions of the assembly on the same machine.


You could try the following. It might be a workaround, or you might be able to find out what the actual problem is:

  • load the .NET dll in Visual Studio
  • in the project properties, on the Debug tab, set Start action to "Start external program" and set it to "C:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE"
  • F5, now vb6 will start
  • load your VB6 project in the VB6 debugger
  • debug.


I've have had the same problem (legacy VB6 application utilising some .NET based DLL's via ActiveX COM). To get this to work I've had to do the following (it may be possible to skip some of the following, but I know each has been required at one point or other):

  1. Copy the DLL and TLB files to the folder where the VB6 IDE EXE resides (e.g. C:\Program Files (x86)\Microsoft Visual Studio\VB98). Messy and annoying, but I've not found an alternative.
  2. Add a suitable VB6.exe.config file (as described above).
  3. You may also need .config files for the DLL's themselves (e.g. if you .NET DLL is named abc.dll, the config file will be abc.dll.config). It seems some stuff will be read from the VB6 config file, and other stuff from the DLL config file. Its probably possible to work out what comes from where, but its easiest just to make the two config files the same.
  4. Make sure you have applied VB6 SP6.
  5. Run the VB6 IDE as administrator.
  6. Run the VB6 IDE in XP SP3 compatibility mode.

This is something of a shotgun approach, but using the above I can still use the VB6 IDE under Windows 8.1 64 bit and debug VB6 code (and even the .NET COM components by attaching the Visual Studio IDE).


found almost similar solution. I've Windows 11 22H2. Visual Basic 6 with SP6 with all patches applied.

First copy my 3 files to c:\windows\syswow64

copy mydll.tlb c:\windows\syswow64
copy mydll.dll c:\windows\syswow64
copy mydll.pdb c:\windows\syswow64

Then register library:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm /verbose /tlb:"c:\windows\system32\mydll.tlb"

I've used that vb6.config.exe file (copied to C:\Program Files (x86)\Microsoft Visual Studio\VB98)

`<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727"/>
    <requiredRuntime version="v2.0.50727" safemode="true"/>
  </startup>
</configuration>`

Then mklink my .dll, . tlb and .pdb file in C:\Program Files (x86)\Microsoft Visual Studio\VB98\

mklink "C:\Program Files (x86)\Microsoft Visual Studio\VB98\mydll.pdb" "\windows\syswow64\mydll.pdb"
mklink "C:\Program Files (x86)\Microsoft Visual Studio\VB98\mydll.dll" "\windows\syswow64\mydll.dll"
mklink "C:\Program Files (x86)\Microsoft Visual Studio\VB98\mydll.tlb" "\windows\syswow64\mydll.tlb"

And now i can debug my libray (.net utility in a com activex) in VB6 IDE.

Regards,

0

精彩评论

暂无评论...
验证码 换一张
取 消