現在、実稼働環境で使用されている C# .NET で記述されたアプリケーションがあります。明らかにリリース ビルドが使用されます。
残念ながら、特定の条件下でアプリケーションが誤動作することがありますが、その理由はわかりません。社内で問題を再現することはできません。はい、より多くのトレースが役立ちますが、多くの場合、より多くのトレースを配置する必要があることに気付いたのは事後です。
通常の行ごとの Visual Studio プロセスへのアタッチ タイプのデバッグを使用して、そのインストールをデバッグする最良の方法は何ですか。顧客のマシンに VS のエクスプレス エディションをインストールし、DLL をデバッグ バージョンに置き換えますか? PDB と特定のソース ファイルを送信するだけで十分ですか? より良い方法はありますか？最終的な目標は、問題をデバッグするための環境のような開発を行うことです。
リモート デバッグは優れた機能ですが、ドメイン (自社と顧客) 間の双方向の信頼が必要であるため、運用環境で使用されることはほとんどありません (両社の管理者はこの考えに強く反対します)。
ドメイン間のリモート デバッグを参照してください。
ただし、アプリケーションで PDB ファイルを送信すると役立ちます。顧客に Clr デバッガー ( DbgCLR.exe )を使用するように依頼できます。これには VS デバッガーと比較していくつかの制限がありますが、それでも作業を実行できるデバッガーであり、.NET SDK の一部です。問題が Clr Debugger でデバッグできない場合、お客様は実稼働環境に VS の試用版をインストールして、リモート デスクトップ接続を提供することができます (管理者がこれを許可している場合)。問題を解決するには90日間の試用期間で十分だと思います
また、顧客が持っているようなテスト環境の構築を試みることもできます。物理的な条件にできるだけ一致するように、CPU やメモリなどの数を制限 (または増加) します。追加のサード パーティ ソフトウェアまたは存在しないレジストリ レコードがプログラムに影響を与える可能性があると思われる場合は、顧客に Windows の仮想イメージを作成するよう依頼してください。
ただし、私の経験では、.NET でのこのような「再現不可能な」エラーの 50% は、複数のユーザーによる同時アクセス (デッドロック、競合状態、First Wins/Last Wins シナリオでの論理的な誤動作) が原因で発生します。ほとんどの場合、これらは顧客のマシンに VS をインストールしてもデバッグできないエラーです (ラッシュアワー以外でこれを実行する場合)。これは、異なるマシンで少なくとも 2 人の顧客を同時に実行する必要があるためです。
したがって、顧客にデバッグを提供するオプションを探している間は、追跡機能と監視機能の改善に取り組み続けてください。多くの場合、トレース カウンターとパフォーマンス カウンターは、運用環境における唯一の友人です。
まず、アプリでPDBをデプロイしたことを確認します（リリースPDBで十分です）。次に、本番マシンにVisual Studioリモートデバッガーをインストールして実行すると、ローカルマシンからデバッグできるようになります。リモートデバッガーはいかなる種類の同期も行わないと思うので、デプロイされたマシン上のアプリのPDBファイルはローカルバージョンと一致する必要があります。
エンタープライズライブラリの例外処理アプリケーションブロックを利用することをお勧めします。これを使用すると、エラーメッセージを電子メール/データベース/テキストファイルなどに記録できます。エラーの背後にある原因を正確に把握できるようにします。
ステータス メッセージとログ ファイルを使用して、少なくともエラーの原因となっているコード行を特定します。