Tracing with Visual Studio 2008 works only the 1st time

[MatLaroche]

Hi,

I'm using Visual Studio 2008 and TestStand 4.1.1. 

I have a C# dll and I'm calling a function from TestStand.

In VS, I "Attach to process..." and choose to attach it to TestStand. I start my sequence and VS come up to the break point I've set in VS.

Everything is great.

Now if I "Stop Debugging", I make some modifications to my dll, recompile Ok and then Re-attach to TS, everything seems ok.

But if I start my sequence, my breakpoints don't hit and the step executes without letting me to trace in my c# code.

The only work-around is to close TestStand, restart it, reopen sequence, and reattach VS to it, then my breakpoint will work again.

What's wrong? I shouldn't have to restart TestStand everytime I make change to dll and reattach it. I tried to Unload all modules also with no success.

 Am I doing something wrong or any solutions to avoid restarting TestStand after making changes to c# code and wanting to trace it.

Thanks.

[Eric_B. · Accepted solution]

Hi Mat,

First, I tried to replicate what you experienced following your instructions, but I couldn't recompile the DLL after stopping debugging from Visual Studio, because the DLL was still in use by TestStand.  After I unloaded all modules, I could recompile.  I then re-attached and saw what you did.  So, to get around it, I attached to the process in a slightly different way.  In Visual Studio, I went to Tools»Attach to Process, then selected the seqedit.exe process.  Before attaching, I pressed the select button on the right of the dialog in the middle to modify the type of code that we are debugging.  Select the "Debug these code types" radio buton and only check "Managed".  This will make sure the debugger only attaches to the managed (C#) code.  After I did this, I could run my sequence again without having to restart TestStand.

Let me know if this works for you.

[MatLaroche]

Yeah you are right, that was the problem.

The "Attach to process..." was set to "Automaticaly determine the type of code to debug" .

By doing this, VS was wrongly choosing Script instead of Managed.

Thank you.

[chouch]

Eric,

I had a similar issue. I followed your procedure and attach the process in the way you described. But, when I try to unload modules it does not seem to work. Visual studio still complains that the DLL is being used. I had some stationglobals that were used in my code that I manually release the reference but it is does not seem enough.

Does anybody has a similar issue?

I am using teststand 4.2, visual studio 2008 sp1, measurement studio 8.6.

Regards,

Loic 

[Eric_B.]

Loic,

When are you trying to unload your modules?  That is only necessary if you are recompiling your DLL, and you would have to do that once your TestStand execution is completed.  Are you just unable to recompile your DLL after executing your TestStand code?

[chouch]

Eric,

That's correct. I am unloading modules after my TestStand sequence execution and I am about to recompile my code. And if my sequence has run once, I am never able to recompile the DLL.

Can some stationGlobals with references to objects prevents to unload modules correctly? Or that my DLL is creating things that are not properly cleaned up after execution?

[Eric_B.]

chouch,

Yes, if you are storing a reference to an object in a StationGlobal or FileGlobal, the module will not be unloaded.  This KnowledgeBase article gives more information on why that occurs: http://digital.ni.com/public.nsf/allkb/8C40CE8535A74FF08625762000763686?OpenDocument .  To resolve this issue, set those StationGlobals to Nothing in a Cleanup step in your MainSequence.

[chouch]

Hello,

Finally found out what it was: I was using a modified process model which was not cleaning behind itself...

Thanks for the support,

Loic