コンパイル済みだがサポートされていないASP.NET Webサイトに変更が必要だった小さなプロジェクトが終了しました。コードは醜いものでしたが、それがコンパイルされる前は醜いものでした。そして、すべてがまだうまくいくように見えることは非常に印象的です。Reflectorで逆コンパイルされたASP.NETでどれくらいの成功を収めていますか？
編集に時間がかかりました。制御宣言が生成されたファイルに入れられ、デコンパイルされた基本クラスと競合するときに削除されますが、数時間で修正されませんでした。
今、私はどれくらい多くの人がこれを成功させているのか不思議です。私は、逆のエンジニアリングプロセスを自動化しないのであれば、それを定義するためのCodeProjectの記事を実際に書いてみたいと思います。
ます：原因.NETプラットフォームに存在するすべてのコンパイラ砂糖
は幸い、この特定のアプリケーションは非常に簡単でしたが、私はにコンパイルすることを期待しないでください元のコードを元のコードと同じように動作させたり、元のコードがどのように動作しているかを把握したりして、新しいコードをスプライスすることができます。
.NETプラットフォームに存在するすべてのコンパイラのため、非常に洗練されたデコンパイラを使用せずに元のコードにバイナリを逆コンパイルすることはできません。たとえば、エンクロージャを処理するためにバックグラウンドでクラスを作成します。この種のものを自動化するのは、それが難しい作業であるように思えます。しかし、それをコンパイルするために予想される問題を処理することは、スクリプト可能である可能性があります。
私は同様のことをしなければなりませんでした。私がコードを持っていた場合よりも、私は実際に幸せでした。私にはそれほど時間がかかりませんでしたが、コンパイラが最適化した後のコードの品質は、おそらく元のコードよりも良かったでしょう。そう、単純なアプリケーションであれば、それをリバースエンジニアリングするのは比較的簡単です。一方で、私は将来それをしなければならないことを避けたいと思います。
.NET 1.1または.NET 2.0で書かれた場合は、主にVS20コンパイラでコンパイルされたものよりもはるかに成功します。主な理由は、新しい言語リビジョンがもたらされたためです（ラムダ、匿名クラスなど）。コードが、あなたはあなたがVSにそれを置く場合は、実行可能なコードを取得するには、リフレクタを使用することができるはずです難読化ではなかったよう
限り、あなたはimmidiately エラー反映コードでを見つける必要があります。
<>で始まる変数/メソッドを見てみると、（特に.NET 3.5を反映している）多くのことがわかります。
最悪の場合はVSにすべてエクスポートし、コンパイルしてエラーの数を判断してから呼び出します。
しかし、それが単純なプロジェクトであれば、リフレクターからリバースエンジニアリングすることができます。少なくともリフレクターを使用して、コードが行っていることの一般的な要点を得てから自分自身をコード化します。