tags:

views:

197

answers:

2

I'm loading a dll (c#) from QTP. Is it possible to debug the c# code when the qtp test starts.

+2  A: 

You can insert a call to Debugger.Break()and run the external application, when the break point will be reached Windows will offer you to debug the exception.

Choosing debug will enable you to run the code after the break inside Visual Studio and set break points inside your code.

In case you're using Vista/Win7 you might need to enable debugging - have a look at this post to learn how.

Dror Helper
There is no reason to change the code to do this... you can easily just attach the debugger yourself.
Brian ONeil
This is useful if you need to be able to break at something that runs automatically when the application starts. If your breakpoint happens after user input then a normal attach is fine, but otherwise you might not be able to attach and set the before the code you want to debug is hit. I've run into this situation a few times with a C++ DLL I worked on.
Herms
true that timing can be an issue, but in this case QTP runs tests and you can control when the tests execute so it shouldn't be an issue (as far as I know)
Brian ONeil
+5  A: 

Yes you can debug into the dll's you can, but you will need source (unless you want to look at the disassembly) and you will also need the PDBs (debug symbols) for the assembly. It is pretty easy to setup...

  1. start the QTP application
  2. start visual studio
  3. open the source code and make sure the pdb's are in the same directory as the dll
  4. in VS go to the debug menu and select attach to process
  5. In the process list, select the QTP process and click "attach"
  6. Set a breakpoint in the code
  7. Start the tests that execute the code and if all is well you should hit the breakpoint

NOTE: if the breakpoint is not hit, VS probably can't find the PDB's and you either need to add a path in options in VS (or something so it can find them).

Also, try turning off "Enable just my code" in the Tools->Options->Debugging options page if it is still not working (mostly if you are looking at release built code).

Update: Answering comment... If you go to Tools->Options... Select "Debugging" on the list on the left and expand that, then select "Symbols" you can add paths there for VS to search for symbols. Also, if you don't have the exact symbols you can right-click the breakpoint and select location and check the option that will allow the symbols to be out of sync.

Hope this helps!

Brian ONeil
this is a better approach...
Ramesh Vel
it's generally better, but the Debugger.Break() solution will work in some cases where this won't.
Herms
Thanks for the reply. But as you said VS probably is not finding the path of PDB even though it's in the same folder with the dll. Where can I mention the path of the PDB?
Learner
I updated the answer with where to update it... Also, you can watch the output windows, it will list symbols as they are loaded so you can see what is going on. I they will not be loaded until something actually accesses the assemblies.
Brian ONeil
I can see that my dll is being loaded when the test starts in the output window but the breakpoint is not loaded. I have the breakpoint in the Constructor itself. And I have added the path as you mentioned. Is there anything else I can try?
Learner
Did you try changing the option in VS to turn off "Enable just my code"? reading my answer above it is not really clear that I mean to turn it off. Didn't know if you have tried that...
Brian ONeil
I had it turned on before but now I turned it off. But still it doesnt hit the breakpoint. I am getting "The thread 0x238 has exited with code 0 (0x0) in the output window. I wonder since the dll is taking a lot of time to load the symbols (around 4 mins) the thread is being exited and no debug is happening!!
Learner
when you say it is taking a long time to load the symbols, do you mean that it does actually say that it is loading the symbols for it? If you never see the symbols load then you might want to try to force them to load. This article has the steps to load them manually. http://msdn.microsoft.com/en-us/library/x54fht41.aspx
Brian ONeil
Also, when you mouse over the breakpoint what reason does it give you that it will not be hit? You can usually get good information out of that too.
Brian ONeil