vb6 dll different behavior when debugging

Question

This is very common case where i have about 2500 dll's. All of those dll's are made with vb6.

Scenario: Run the main .exe file and call the .dll from it. When running Crystal report view it works as a charm.

Scenario 2: Run the .exe file which is made with .NET through debug mode works as a charm.

Scenario 3: Run the .exe file which is made with .NET through RUNTIME Throw the exception shown bellow.

Description: The process was terminated due to an unhandled exception. Exception Info: exception code c0000005, exception address 0F5E6BD0

Full stack message available on link: Full exception message

Tried with two ways.

Adding the .dll to .exe as a references
Adding it through CreateObject

This is one my my work.

Dim obj As Object
obj = CreateObject("Partneri.clPartneri")

Microsoft.VisualBasic.CallByName(obj, "PrikaziFormu", CallType.Method, cConrADO,
                                         cConADO, False, "", cJezik, rTagovi, rPrevodi, rPrava, 0, 0, cUsername)

Please keep in mind: When running this through debug everything works great.

The only workaround which i am using now is going like Create .exe made in vb6. Call that .exe from .net exe and pass a option name as a parameter. On form load it will set up the object which works great.

Additional: When running crystal report print on load throws

VB6 is 32-bit only. Is your .NET application is running as 64bit when the error occurs? — StayOnTarget
i think you shoul d try something like this stackoverflow.com/questions/52540578/… , but for 5000 dlls i hope you get a better answer — nbk
@DaveInCaz you wouldn't believe how much i expected that would solve the issue. Setting the Target CPU - x86 didn't solve it — Programer Anel

Adam Cruickshank Adam Cruickshank · Accepted Answer · 2019-06-29T17:29:03

Have you tried running the exe as administrator to rule out if it’s a permissions thing? In debug mode you’re probably running as admin, but the exe won’t be.

I had similar errors when calling .NET COM interop dlls from VB6, but that was caused by using inheritance in the .NET classes. Or so it seemed.

vb6 dll different behavior when debugging

1 Answers