by dmilov at 2013-01-21 05:41:49
Hello,by DonJ at 2013-01-21 16:04:31
I’m using powershell debugger in nested powershell process. It works in PS2.0 but doesn’t in PS3.0. The way I’m doing this is as follows:
1. Put the following in profile script (Microsoft.PowerShell_profile.ps1)
Set-PSBreakpoint -Script ‘c:\myscript.ps1’ -Line 34
2. From powershell console I run my script in separate powershell process
powershell.exe c:\myscript.ps1
In PS2.0 the powershell debugger breaks at line 34 and I’m able to debug my script.
In PS3.0 it doesn’t work, doesn’t break at my breakpoint. I know the breakpoint is set on 34 line because I see Set-PSBreakpoit output an I see in the execution output the message that breakpoint has been hit.
I’ve tried to break with nested prompt ($host.EnterNestedPrompt()) in my script but it doesn’t work as well.
If you have an idea why PS3.0 behaves this way or have any suggestions, please share.
Thank You!
3.0 was revised pretty heavily, and even runs in a different runtime (DLR vs. CLR). It’s not surprising to see something like this behave differently. It’s even possible that the original behavior wasn’t by design, meaning you were working with a loophole. I don’t work for Microsoft, so I can’t give you a definitive answer, but that’s my informed guess.by dmilov at 2013-01-22 05:08:16I’m not sure breakpoints were ever intended to "inherit" that way.
I’m curious - is there a reason you run the script in a separate process?
Yes I have a reason to start scripts in separate processes and it is: I work with many scripts and I want each one to run in clean PS sessions, variables from one script could affect another and starting it in new process is the best option for me.by DonJ at 2013-01-22 05:59:08
You might consider adding the Set-PSBreakpoint commands to the script itself, then. That’s the only for-sure way I know of to have the breakpoints set within the runspace where the script is executing. I actually tend to use Write-Debug as opposed to breakpoints, for this exact reason. I can turn on debugging by running the script with -Debug, otherwise it’s off, and the "breakpoints" travel along with the script and whatever runspace it’s in. Write-Debug isn’t as flexible as breakpoints, but for "setting" a simple line breakpoint like you’re doing, it’s effectively the same. Plus, the Write-Debug’s "move" as you edit the script, so that your breakpoint always stays in the same place even if the line number changes. Just a thought.