App config settings are not a good choice for this because Gallio gets
embedded in a lot of different apps all of which would need to be
changed.
Two options that could work well together:
1. Add a DebuggerTypes property to HostSetup then modify IDebugger to
receive the types as a parameter. Also add in a query for debugger
types. The types could be enumerated in plugin metadata so we avoid
having to launch Visual Studio just to get then. (Caveat: we will have
to edit the plugin metadata whenever a new well known type becomes
available).
Then we can add extra command line arguments to Echo et. al and a GUI
preference for Icarus.
We could make up a new IDebuggerManager to support these queries and
act as a factory for IDebugger. This is good because we need to deal
with non Visual Studio based debuggers at some point.
2. I think it is possible to switch debuggers at runtime (can detach
then attach at the least) so we could provide a debugger hint
attribute for the tests.
[Debugger("Managed", "Native")]
Jeff
On Apr 23, 2009, at 6:44 AM, "Rob Prouse" <[email protected]> wrote:
>
> I think that available debugger engines is very dependent on the
> debugger we
> are using. If in the future we want to support other debuggers than
> Visual
> Studio, then those command line options would probably complicate
> things.
>
> Also, looking at the code, getting the HostSetup to the debuggers
> would
> require changes to several interfaces.
>
> This is fairly important to us though, so I don't mind doing the
> work. What
> if we kept it simple? I could add application settings to the
> VisualStudio.Interop project to specify the debuggers to load, then
> add
> those settings to the app config files for Echo and Icarus with the
> extra
> engines commented out.
>
> This way, people who need this functionality can easily turn it on
> and the
> majority that don't won't be affected. We could also support other
> debugger
> specific options in the future which might come in handy for Mono.
>
> If this is okay, I will get it done and submit a patch.
>
> Rob Prouse
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Jeff Brown
> Sent: April-22-09 4:31 PM
> To: [email protected]
> Cc: 'Jamie Cansdale'
> Subject: MbUnit Re: Native Debugging
>
>
> Hmm.
>
> I think we'll have to settle the problem of configuring the
> debuggers then.
> Several people have already that single stepping through a test is
> too slow
> so I hesitate to add much more overhead if possible. (The problem
> is that
> the MbUnit stack is pretty deep. I'll have to rearrange the code to
> cut
> down on stack depth.)
>
> I guess the debugging Api could be extended with an option to
> specify the
> debugger types. I guess it would also need a way to enumerate the
> available
> debuggers. Then things get complicated.
>
> I wonder how ReSharper and TestDriven.Net handle this problem. Do
> they only
> launch the Managed debugger?
>
> Jeff.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Rob Prouse
> Sent: Wednesday, April 22, 2009 12:56 PM
> To: [email protected]
> Subject: MbUnit Re: Native Debugging
>
>
> The only problem that I have seen is that it is a little bit slower
> to step
> through code while debugging. If that is a problem, which debuggers
> are
> attached could easily be a configuration option. For example, we
> could also
> attach T-SQL, Script or Workflow debugging engines. It will be very
> obvious
> in the code.
>
> Also, I wrote it so that if it has trouble using the EnvDTE80
> interfaces, it
> will fall back to managed only debugging using the old interfaces.
>
> I have attached the patch to issue #431.
>
> Thanks.
>
> Rob Prouse
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Jeff Brown
> Sent: April-22-09 3:10 PM
> To: [email protected]
> Subject: MbUnit Re: Native Debugging
>
>
> Please open up an issue and attach the patch. That way I won't
> forget to
> apply it!
>
> Do you think there could be any problems with attaching the Native
> debugger
> all of the time? I've had it go a little nuts on me before although
> mainly
> during remote debugging sessions.
>
> Thanks!
> Jeff.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Rob Prouse
> Sent: Wednesday, April 22, 2009 11:49 AM
> To: [email protected]
> Subject: MbUnit Native Debugging
>
>
> Some of our test suites call into Native code, but we cannot step
> into the
> native code when using the new debug command line or button in Icarus.
>
> I have a patch for Gallio.VisualStudio.Interop.VisualStudioDebugger
> that
> attaches the Managed and Native debuggers using EnvDTE80 instead of
> EnvDTE.
>
> Should I open an issue and add the patch, or is this such an
> isolated case
> that this feature shouldn't be added?
>
> Thanks.
>
> Rob Prouse
>
>
>
>
>
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MbUnit.User" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/MbUnitUser?hl=en
-~----------~----~----~----~------~----~------~--~---
