Stepping between .Net IDE into a VB6 dll call

[scl]

I have an application with a .Net front end that makes calls into a series
of VB6 dll's via COm InterOpt. Although everything works quite well, the
main issue that I have is regarding the overall debugging workflow.
Ideally, I would like to configure my IDE's such that when I am stepping
through my .Net code that makes a call to a VB6 dll method, I am able to
step into the VB6 IDE to continue the debugging process. Currently, I
cannot step into the VB6 call: it simple is executed in a single big step.

I have recently found out that the reverse situation is true: one can be in
the VB6 IDE and when a call is made to a .Net dll, we can step into the .Net
IDE for further debugging. However, it should be noted that upon exit from
the .Net IDE, the VB6 IDE is terminated. Although this is far from ideal,
it does still offer some useful capabilities.

Although COM InterOpt is nice, I think that seemless debugging between bothe
IDE's is required to make the development task efficient. At the very
least, the .Net IDE should be able to include the capability to debug VB6
code directly. This issue is the primary reason I am reluctant to mix both
plaforms. For those with a very large VB6 code base, I cannot imagine how
else they would want to proceed in an efficient manner.

Any ideas or comments?

[Ken Halter]

"scl" <as******@structural-concepts.com> wrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

I have an application with a .Net front end that makes calls into a series
of VB6 dll's via COm InterOpt. Although everything works quite well, the
main issue that I have is regarding the overall debugging workflow.
Ideally, I would like to configure my IDE's such that when I am stepping
through my .Net code that makes a call to a VB6 dll method, I am able to
step into the VB6 IDE to continue the debugging process. Currently, I
cannot step into the VB6 call: it simple is executed in a single big step.

I've never tried it (no dotNet projects) but, have you tried loading that
VB6 DLL up in the IDE and setting the debug options (Project/<Your Project>
Properties/Debugging tab) to 'Wait for components to be created'? I have no
idea what effect interop has on that environment. It should be worth a try
though.

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[Ken Halter]

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%2*****************@TK2MSFTNGP02.phx.gbl...

I've never tried it (no dotNet projects) but, have you tried loading that
VB6 DLL up in the IDE and setting the debug options (Project/<Your
Project> Properties/Debugging tab) to 'Wait for components to be created'?
I have no idea what effect interop has on that environment. It should be
worth a try though.

Forgot to mention... but you probably already know...

Of course, following the steps above, you'd have to tell the IDE to start
running the DLL... and it would sit and stare at you until you run an app
that requires the DLL.

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[Herfried K. Wagner [MVP]]

"scl" <as******@structural-concepts.com> schrieb:

Although COM InterOpt is nice, I think that seemless debugging between
bothe IDE's is required to make the development task efficient. At the
very least, the .Net IDE should be able to include the capability to debug
VB6 code directly. This issue is the primary reason I am reluctant to mix
both plaforms. For those with a very large VB6 code base, I cannot
imagine how else they would want to proceed in an efficient manner.

You are not the only one asking for this functionality. Check out the
second link in my signature (though it won't solve the problem).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[scl]

Ken,

Thanks for the feedback. I also received a similar suggestion by Scott
Swigard. In principal, this seems to work in some cases. However, for a
number of my dll's, I am getting various automation errors in the Vb6 dll's
when they are running. Everything works fine (eg the com interopt) when the
dll's are not running. It's proving to be difficult to pinpoint the
underlying issue. All my dll's are compiled with binary compatibility and
they work fine in normal usage. Problems are occuring when running one of
the dll's for debugging purposes. Pretty frustrating!

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:uo**************@TK2MSFTNGP02.phx.gbl...

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%2*****************@TK2MSFTNGP02.phx.gbl...

I've never tried it (no dotNet projects) but, have you tried loading that
VB6 DLL up in the IDE and setting the debug options (Project/<Your
Project> Properties/Debugging tab) to 'Wait for components to be
created'? I have no idea what effect interop has on that environment. It
should be worth a try though.

Forgot to mention... but you probably already know...

Of course, following the steps above, you'd have to tell the IDE to start
running the DLL... and it would sit and stare at you until you run an app
that requires the DLL.

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[scl]

I agree.