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 -~----------~----~----~----~------~----~------~--~---
