M
matvdl
Guest
We have an old legacy VB6 exe application (Active X exe with thread er object) and this uses come .net assemblies through com Interop. These .net assemblies are fairly basic and they are compiled and registed with regasm to enable them to be exposed to the VB6 application.
These assemblies also reference the VB6 application and the VB6 application is exposed to .NET using the tlbimp . This allows us to create code in .net that extends the existing application with early binding back to the calling VB6.exe.
the VB6 application is multi-threaded and initializes a number of threads that operate independently of each other.
I have found on occasion that from different VB6 threads calling into the .net assembly the system will hang? When I debug the hanging VB6 application I can see that both VB6 threads are stuck on a call out to the .net assembly.
As these are operating in different apartments I would not have thought this should occur? Is there a setting within .NET dll that I need to use to prevent this type of behaviour?
matvdl
Continue reading...
These assemblies also reference the VB6 application and the VB6 application is exposed to .NET using the tlbimp . This allows us to create code in .net that extends the existing application with early binding back to the calling VB6.exe.
the VB6 application is multi-threaded and initializes a number of threads that operate independently of each other.
I have found on occasion that from different VB6 threads calling into the .net assembly the system will hang? When I debug the hanging VB6 application I can see that both VB6 threads are stuck on a call out to the .net assembly.
As these are operating in different apartments I would not have thought this should occur? Is there a setting within .NET dll that I need to use to prevent this type of behaviour?
matvdl
Continue reading...