The VB6 App + .Net component works as a compiled application, but not in the VB6 IDE

Question

I have a VB6 application that uses the .Net component (via the .tlb link in a VB6 application), which works fine when executed as a compiled application, but throws an error from the VB6 IDE at some point when it tries to use the .NET component.

It should be noted that the error occurs when the .NET component is designed to invoke a third-party reporting component. The error relates to the reporting component. Something about the inability to cast from String to another type.

.Tlb is in the same place as the application executable, so I don’t understand why there should be a problem. There is a .config for one of the DLLs, but it only indicates where the log file should be.

I need the application to run in the IDE to debug and walk through the code. What could be the problem? Can the VB6 IDE look elsewhere for specific DLLs?

Answer 1

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

Create a .config file for the IDE (for example, the EXE name of the executable IDE + .config file).

Insert the following into 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, regardless of the order in which .NET COM components are activated (some of which can be loaded by the IDE, which leads to a mismatch of the runtime in the process).

Answer 2

Like Lucero, I am interested in the configuration file ... I recently had an interaction script in which I needed to create a configuration file for the vb6 executable file in order to get the .net dll to correctly read the settings in the application domain in which it is located. The network library is working. In this case, I was able to take the existing config for dll and copy it as vb6.exe.config, where vb6 is the name of your vb6 executable.

If this thought is true, I agree with Lucero that your * .exe.config file must be linked to the source executable for the IDE ... which I believe is vb6.exe.

Although the vb6 executable itself does not require a .config file to work, the presence of a configuration file will affect any downloadable .net components, so this can make a difference.

You can exclude the configuration file by temporarily programming your settings. If this works in the VB6 IDE, then you know that you are moving in the right direction.

Answer 3

Casting exception is not easily explained by the problem with the standard program directory. What about everything that should be different when you launch the application from the VB6 IDE, and not directly.

You will need to use a debugger to find out what is going wrong. Fortunately, this is easy when you use VB6. Start by opening your .NET project in Visual Studio. Project + Properties, Debug tab. Select "Run external program", click the dots button and go to vb6.exe. It should be located in the c: \ program files \ microsoft visual studio \ vb98 \ vb6.exe folder if you used the default installation options.

You can set the "Command Line Parameters" path to your .vbp project so that the IDE automatically downloads it. Not necessary.

Debugging + Exceptions, check the box "Exclude common runtime language". Press F5 to start the debugger. Now the VB6 IDE will open, if necessary, download the VB6 project. Run the project and recreate the failure case. This should trigger a breakpoint in the Visual Studio debugger. You may need to switch to it manually, the taskbar button should blink. Use normal debugging tools to find out why an exception was thrown.

Note that you can also set breakpoints in Visual Studio, useful if you need to execute one-step code to find out what happened. When you press F5, the breakpoint indicator becomes hollow because the DLL is not yet loaded. Once your VB6 project creates a class object from your .NET code, the DLL will load (visible in the output window) and the breakpoint indicator will become solid. If this does not happen, you may need to run Regasm.exe with the / codebase parameter so that the DLL in the bin \ Debug folder of the project is registered as a COM server.

Answer 4

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

Answer 5

I would try registering 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 this warning if you do not have several versions of the assembly on the same computer.

Answer 6

You can try the following. This can be a workaround, or you can find out what the problem is:

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

Answer 7

I had the same problem (an inherited VB6 application using some .NET-based libraries through ActiveX COM). To get this to work, I needed to do the following (maybe you can skip some of the following points, but I know that everyone was required at one time or another):

1. Copy the DLL and TLB files to the folder where the VB6 IDE EXE file is located (for example, C: \ Program Files (x86) \ Microsoft Visual Studio \ VB98). Dirty and annoying, but I did not find an alternative.
2. Add the appropriate VB6.exe.config file (as described above).
3. You may also need .config files for the DLL itself (for example, if your .NET DLL is called abc.dll, the configuration file will be abc.dll.config). It seems that some things will be read from the VB6 configuration file, and others from the DLL configuration file. You can probably figure out what is coming from, but the easiest way is to make the two configuration files the same.
4. Make sure you apply VB6 SP6.
5. Run the VB6 IDE as administrator.
6. Launch IDE VB6 in XP SP3 compatibility mode.

It's a bit of a shotgun, but with the help of the above, I can still use the VB6 IDE in 64-bit Windows 8.1 and debug the VB6 code (and even the COM components of .NET by connecting the Visual Studio IDE).