Alex Rivera | Logout

Problems debugging a PowerShell cmdlet

Asked 2010-07-25T17:50:08.497
11

I'm using Visual Studio 2010 on Windows 7 64-bit Professional. I'm having trouble debugging a custom PowerShell cmdlet.

Configuration

  • Language: C#, targeting .NET Framework 3.5 SP1.
  • Platform target: Any CPU
  • Start Action: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
  • Command line arguments: -noexit -command Add-PSSnapIn MyCustomSnapIn

Problem 1: Failure to attach when I press F5 (Debug → Start Debugging)

  • PowerShell opens, and Task Manager indicates that powershell.exe is running as a 64-bit process. The Image Path Name column shows the same executable specified in the Start Action.
  • If I choose Debug → Break All in Visual Studio, I receive a message "Unable to break execution. This process is not currently executing the type of code that you selected to debug."

Problem 2: Unexpectedly launches as a 32-bit process when I press Ctrl+F5 (Debug → Start Without Debugging)

  • PowerShell opens. Task Manager indicates that powershell.exe is running as a 32-bit process - this time the Image Path Name shows a SysWOW64 redirection.

The annoying way to debug right now: The only way I've found to debug my cmdlet is to press F5, then select Debug→Detach All, then select Debug→Attach To Process and reattach Visual Studio.

visual-studio debugging powershell powershell-cmdlet
Edit
Report

2 Answers

2

I know that this posting is about a year old at this point, but it may help someone else struggling with this anyway.

I have found that the following scenario works for me with PowerShell 2.0. I am also using VS2010 SP1 on Windows 7 64-bit.

With PS 2.0 you no longer have to install cmdlets using installutil. Instead you can use Import-Module instead (which does not require Admin rights). I will not go into full detail on how that is done as a web search will reveal most details, but in short, you will need to create a folder (if it does not already exist) at:

md (Join-Path (Split-Path $profile) modules)

Under the modules folder, create another folder with the same name as your cmdlet DLL (minus “.DLL”). This folder will contain your binary and a psd1 file that describes your DLL (see Module Manifests). For my convenience I created this folder as a folder symbolic link to my project’s bin\debug folder.

You still need to run PowerShell (or PowerShell ISE) from Visual Studio as describe elsewhere in the “Start Action” section of the Debug tab of your project properties.

Set your breakpoints and go. Once PowerShell starts, type:

Import-Module <ModuleName>

Then run your cmdlet.

Sample

C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.dll 
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.pdb
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.psd1
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.Types.ps1xml (etc.)

In PowerShell type (can be put in your profile too):

Import-Module MyCmdlet

For me, this hits all my breakpoints and al

answered 2011-08-28T00:49:18.413
0

I had this problem with VS2010, but it went away after installing SP1.

answered 2011-10-21T17:50:43.123

Your Answer