現在、大規模な移行プロジェクトを実施しており、ライブエステートにデプロイされているコードがソース管理にあるコードと一致することを検証しようとしています。
明らかに、.netコードは分解できるため、簡単に比較できます。コンパイルの方法のため、これがvb6exeで可能であるとは思わない。
ソースコードを検証し、コンパイルされた実行可能ファイルがLiveにあるファイルと一致する方法について誰かがアイデアを持っていますか?
ありがとう
Visual Basic には 2 つのコンパイル方法がありました。1 つはインタープリター (P コードと呼ばれる) を使用してバイナリを小さくする方法で、もう 1 つは「通常の」Windows .exe ファイル (ネイティブと呼ばれる) を生成する方法です。 p-code よりも高速であると想定されていました。ただし、このオプションを使用すると、コンパイルされたファイルのサイズが増加します。コンパイルで p-code を使用していた場合、理論的にはソースを復元することができます。
どちらの方法もかなり難しいですが、これを部分的に行うことができると主張するツールがあり ます。 /
残念ながら、それはほとんど不可能です。異なるマシンでコンパイルされたVB6コードには、異なるexeサイズと展開要件があることに注意してください。
これが、古いVB'erがコードをコンパイルするための専用マシンを持っていた理由です。
私の古い会社はそのVB-Decompilerのコピーを購入し、VB5 / 6が追加のP-Codeを生成する前に述べたように、そのツールはいくつかのコードを生成し、そうでない場合は「読み取る」ことができるアセンブリコードを生成しました。
作成したさまざまなライブラリとexeをチェックアウトし、それらを自動的にコンパイルできる信頼できるコンピュータを用意します。それらは読み取り専用ですがアクセス可能な場所に保管してください。次に、デプロイされたサイトと比較サイトの間でバイナリ比較を行います。
ただし、コンパイルされたユニットを逆アセンブルするロジックについてはよくわかりません。私の会社と私が知っている他のほとんどの場所では、ビルドコンピューターと単体テストを組み合わせて使用しています。私たちの会社では、私たちが作成するEXEは、多数のライブラリ上の非常に薄いシェルです。たとえば、ボタンのクリックは、実際の処理を行うUI ActiveXDLLに渡されます。ビルド後に行うことは、単体テストのリストを実行する特別なEXEを実行することです。それらがすべて合格した場合、コードの90%が含まれているライブラリが適切であることがわかります。実際のEXEについては、手作業で約2時間かかりますが、それで問題ありません。IItは、EXEでエラーが発生することはまれです。
コンパイルしたすべてのコードがあれば、そのコードの CRC を現場で展開されているものと比較できます。ただし、元のコンパイル済みコードがない場合は、コードをどのようにコンパイルしたかによって異なります (ネイティブ コードではなく P コードを使用した場合、逆アセンブルできる場合がありますが、逆アセンブリはソース コードとはまったく異なります)。PDB を exe と一緒に出荷したとは思えませんが、出荷した場合は、それらを使用して、リポジトリ内のソース コードと比較することができます。
これはすでにデプロイされているアイテムには役に立ちませんが、コンパイルごとにリビジョン番号を上げていれば (自動的にこれを行うプロジェクト設定があります)、バージョン番号を簡単に比較できます。