アプリケーション用のプラグインロジックを使用して（Visual C＃Expressで）DLLを開発しています。
アプリケーションで使用された後、このDLLをデバッグする方法はありますか？このアプリケーションはWindowsでサービスとして実行されており、COTSアプリケーションです。つまり、デバッグを開始できるC＃プロジェクトではありません。
Visual C＃Expressでのデバッグに関して制限があることを認識しています。このタスクはVisualStudioProで可能ですか？
私が達成したいのは、ロジックをステップスルーし、ブレークポイントを設定して、呼び出しが来たときに何が起こるかを確認できるようにすることです。手がかりはありますか？
VS Expressについてはよくわかりませんが、通常は
それが役に立てば幸い。
これがサービスでどのように機能するかは完全にはわかりませんが、任意のデバッグターゲットを設定できます。
デバッグパネル（プロジェクトプロパティ内）で、任意の実行可能ファイルまたはその他のコマンドをデバッグターゲットとして設定できます。このコマンドによって生成されたプロセスには、実行可能ファイルがどこから来たかに関係なく、デバッガーがアタッチされます。ターゲットがC＃プロジェクトまたはVisualStudioプロジェクトである必要はありません。これは、ExpressとProの両方で利用できるはずです。後のプロセスにアタッチすることは可能ですが（ランチャーがある場合）、それはおそらく現在の範囲を超えています。
次に、通常どおりコードにブレークポイントを設定します。コードがヒットすると（コードがコードを呼び出すかホスト実行可能ファイルを呼び出すかに関係なく）、ブレークポイントがトリガーされます。ホストに関する情報の量によっては、ホストを効果的にデバッグできる場合もあります。情報がない場合でも、アセンブリをステップ実行できます。
ここでの唯一の要件は、ターゲットがコードをロードして実行することです。コンテキスト（プログラムへのプラグイン、注入された依存性など）に応じて、これはさまざまな難しさです。この手法は多くの場所で使用されています。特に、実際のホストをデバッグできない可能性があるプラグインシステムでは、プラグインを使用してデバッグする必要があります。
もう1つの少し醜いバリエーションは、ホストを強制的に破壊して自己識別させることです。これは非常に混乱を招くため、デバッグにのみ役立ちます。一般的な方法は、プロセスIDを含むメッセージボックス（モーダル）を表示することです。その後、メッセージが閉じられ、デバッガーを接続できるようになるまで、プロセスは中断されます。これはサービスではさらに困難になりますが、情報をブロックする方法で公開する方法はまだあります。
System.Diagnostics.Debugger.Break（）メソッドを使用できます。