11

Windows 7 64 ビット Professional で Visual Studio 2010 を使用しています。カスタム PowerShell コマンドレットのデバッグに問題があります。

構成

  • 言語: C#、.NET Framework 3.5 SP1 を対象。
  • プラットフォーム ターゲット: 任意の CPU
  • アクションの開始:C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
  • コマンドライン引数:-noexit -command Add-PSSnapIn MyCustomSnapIn

問題 1: F5 を押しても接続に失敗する (デバッグ → デバッグ開始)

  • PowerShell が開き、タスク マネージャーに、powershell.exe が 64 ビット プロセスとして実行されていることが示されます。[イメージ パス名] 列には、開始アクションで指定されたものと同じ実行可能ファイルが表示されます。
  • Visual Studio で [Debug] → [Break All] を選択すると、「Unable to break execution. This process is not running the type of code that you selected to debug.」というメッセージが表示されます。

問題 2: Ctrl+F5 (デバッグ → デバッグなしで開始) を押すと、予期せず 32 ビット プロセスとして起動する

  • PowerShell が開きます。タスク マネージャーは、powershell.exe が 32 ビット プロセスとして実行されていることを示します。今回は、イメージ パス名に SysWOW64 リダイレクトが表示されます。

現在のデバッグの面倒な方法:コマンドレットをデバッグする唯一の方法は、F5 キーを押し、[デバッグ] → [すべてデタッチ] を選択し、[デバッグ] → [プロセスにアタッチ] を選択して、Visual Studio を再アタッチすることです。

4

7 に答える 7

6

問題 1:

ここで報告された VS2010 のバグのように思えます: https://connect.microsoft.com/VisualStudio/feedback/details/539389/debugging-powershell-cmdlet-from-vs-2010-does-not-stop-at-breakpoints ?wa=wsignin1.0

VS2008 を使用すると役立つはずです。

更新: powershell コマンドレットをデバッグするためのより便利な方法を見つけました。ソリューション エクスプローラーでソリューション ノードを右クリック -> 追加 -> 新しいプロジェクト -> powershell.exe ファイル (C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe) を選択します。新しく追加したプロジェクトをスタートアップ プロジェクトとして設定します (右クリックして [スタートアップ プロジェクトとして設定] を選択します)。次に、プロジェクトのプロパティに移動し (プロジェクト ノードを右クリックして [プロパティ] を選択)、[デバッガの種類] プロパティを [管理対象 (v2.0、v1.1、v1.0)] に設定します。プロバイダーまたはコマンドレットを登録することを忘れないでください (ビルド後のイベントを実行して、http://msdn.microsoft.com/en-us/library/ms714644%28v=vs.85%29.aspxを参照してください)。これで、プログラムはブレークポイントで停止するはずです。

于 2010-07-27T15:01:51.937 に答える
2

この投稿がこの時点で約 1 年前のものであることはわかっていますが、とにかくこれに苦労している他の誰かを助けるかもしれません.

次のシナリオは、PowerShell 2.0 で機能することがわかりました。Windows 7 64 ビットで VS2010 SP1 も使用しています。

PS 2.0 では、 installutilを使用してコマンドレットをインストールする必要がなくなりました。代わりに代わりに使用できます(管理者権限は必要ありません)。Web 検索でほとんどの詳細が明らかになるため、その方法については詳しく説明しませんが、要するに、次の場所にフォルダーを作成する必要があります (まだ存在しない場合)。Import-Module

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

modules フォルダーの下に、コマンドレット DLL と同じ名前 (マイナス ".DLL") の別のフォルダーを作成します。このフォルダーには、バイナリと、DLL を記述する psd1 ファイルが含まれます (「モジュール マニフェスト」を参照)。便宜上、このフォルダーをプロジェクトの bin\debug フォルダーへのフォルダー シンボリック リンクとして作成しました。

プロジェクト プロパティの [デバッグ] タブの [アクションの開始] セクションで説明されているように、Visual Studio から PowerShell (または PowerShell ISE) を実行する必要があります。

ブレークポイントを設定して開始します。PowerShell が起動したら、次のように入力します。

Import-Module <ModuleName>

次に、コマンドレットを実行します。

サンプル

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.)

PowerShell タイプ (プロファイルにも入れることができます):

Import-Module MyCmdlet

私にとって、これはすべてのブレークポイントにヒットし、例外でも停止します。プロセスなどにアタッチする必要はありません。

于 2011-08-28T00:49:18.413 に答える
2

問題 2 では、Visual Studio は WOW64 で実行される 32 ビット プロセスであるため、パスC:\Windows\system32\WindowsPowerShell\v1.0\powershell.exeは にリダイレクトされC:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exeます。これは、PowerShell の 32 ビット バージョンが存在する場所です。

于 2010-07-25T22:24:59.367 に答える
1

問題 1: powershell.exe は実際には管理対象の実行可能ファイルではありません。これは CLR 自体をホストするため、これを機能させるには、マネージと共にネイティブ コードのデバッグを有効にする必要があります。

問題 2 については、よくわかりません。明らかに VS 自体は 32 ビット プロセスなので、ここで干渉している可能性があります。

于 2010-07-25T22:06:46.260 に答える
0

C:\dev\PowerShell\x64フォルダーを作成し、そこからすべてをコピーすることで、問題＃2を解決できましC:\Windows\System32\WindowsPowerShell\v1.0た。同様のフォルダを作成しましたC:\dev\PowerShell\x86。これらのパスを指定すると、目的のバージョンの PowerShell が常に起動するため、デバッグを開始する最短の方法は、[デバッグなしで開始] の後に [プロセスにアタッチ] を選択することです。

于 2010-07-26T13:31:00.073 に答える
0

VS2010 でこの問題が発生しましたが、SP1 をインストールすると解消されました。

于 2011-10-21T17:50:43.123 に答える
0

Add-PSSnapin を呼び出してデバッグ セッションで使用できるようにする前に、プラグインをインストールする方法については言及しません。

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe...\Framework... のプラグインではなく、を使用してプラグインをインストールしていることを確認してください- これは数日間私を困惑させました。

于 2010-08-20T19:34:17.757 に答える