5

私のクライアントには、1 年前にコンパイルおよびデプロイされたコンパイル済み ASP.NET 2.0 アプリケーションがあります。また、ソース管理下にないソース コード プロジェクト/ソリューションの 4 つのバージョンがあります (以前の開発者のワークステーション ファイル システムに保存されています)。互いに一致するファイルの日付はありません。

これらのバージョンのどれが実際に運用 Web サイトにデプロイされているか (存在する場合) を特定する方法はありますか?

4

4 に答える 4

5

私はこれをクライアントプロジェクトで複数回行い、他のコメンターと同様にReflectorを使用しています。この種のことは、本来よりも頻繁に起こります。たとえば、誰かが突然開発チームを離れたとき。あるプロジェクトでは、開発チーム全体が去った後に請負業者のチームが呼ばれ、実際に手元にあるものを確認するために、本番環境で実行されているすべてのコードでこの手順に従う必要がありました。

私がそれに対処する方法は、ファイルシステムの別の領域で利用可能なコンパイル済みコードのすべてのバージョンを取得することです。これには、ソース管理されているバージョンまたは開発ワークステーションから離れているバージョンが含まれます。リフレクターは実際の元のソースではなくILを認識し、リンゴとリンゴを比較する必要があるため、これは重要です。

FileDisassembler for Reflectorを使用して、各バイナリを個別のフォルダーに逆コンパイルします。最終的には次のような構造になります。

ProjectXyzReconciliation
|-プロダクション
|-ステージング
|-テスト
| -qa
| -devworkstation
| -sourcecontrol
|-調整済み（これは最終的にソース管理に戻るものです）

次に、WinMergeを使用して（ただし、他のマージ/比較ツールも同様に使用しました）、ディレクトリを比較して「調整済み」フォルダにマージします。私は通常、本番環境で実行されているものを最初に入力し、他のすべてのバージョンと比較します。

最初のパスは、実際には何が違うのかを確認することです。ファイルに逆コンパイルすると、WinMergeなどのツールを使用して、意思決定のために実際に何が違うのかをレポートできます。

場合によっては、このプロセスにより、バグ追跡データベースや電子メールなどのバグを簡単に追跡できる1つまたは2つの変更が生成され、今後の作業に参加するか、参加しないかを決定できます。

すべての違いが説明され、後で再作業または削除するためにマージまたは拒否されると、新しく調整されたコードが将来の開発およびリファクタリングの新しいベースとして使用されます。これにより、コードに含まれていたコメントはすべて失われますが、この手順全体が必要になった場合、コメントを失うことは率直に言って大きな損失ではありません。

初めての場合、これは気が遠くなるように思えるかもしれませんが、これが得意な私のチームのメンバーは、後のプロジェクトで、厄介な状況が発生したときに不可能を達成できるように見えることがヒーローのように見えることがよくあります。これをツールボックスに入れる価値があります。

于 2009-07-14T13:30:29.687 に答える
4

私があなたの状況にあった場合、4 つの個別のソース プロジェクトを 1 つずつコンパイルします。次に、.NET Reflector の diff アドインを実行して、実稼働アセンブリと一致するかどうかを確認します。そうでない場合は、次のソース プロジェクトをコンパイルして、もう一度差分を試してください。

于 2009-07-13T19:57:18.313 に答える
1

.NET Reflectorは、特定のサーバーで使用されているコードを確認するための便利なツールです。

于 2009-07-13T19:55:01.390 に答える
1

プロジェクト ディレクトリに DLL や EXE などのビルド アーティファクトが含まれている場合は、バージョン番号を確認して、運用環境のものと比較できます。完全に一致しない場合でも、最も近い可能性があるものが表示されます。

于 2009-07-13T19:53:31.847 に答える