コードがスレッド (System.Threading.Thread) を作成するかどうか、または他の BCL を使用するかどうかを確認するなど、検証要件を適用するために一部のコードを「監査」することがリフレクション (またはその他の方法) によって可能かどうかを把握しようとしています。コードが既に dll にコンパイルされていることを前提としています。ありがとう!
5 に答える
FxCopを見てください。コンパイルされたバイナリ (dll または exe) をロードし、その記述に使用された .NET 言語に関係なく、そのコンパイルされた IL に対して検証とコンプライアンス チェックを実行できます。
独自のルールを作成できます。この場合は、「= new Thread()」などのケースをキャッチするために行います。
IL に精通している場合は、リフレクションを使用してこれを行うことができます。
MethodBody mb = this.GetType().GetMethod( "Method", BindingFlags.Default ).GetMethodBody();
byte[] bytes = mb.GetILAsByteArray();
おそらく、それだけの価値があるよりもはるかに多くの問題があります。結果の IL を解析する必要があります。
IL パーサー (やや古い): http://www.codeproject.com/KB/cs/sdilreader.aspxこれは OpCodes のリストを生成します (スレッドのインスタンス化のために OpCodes.Newobj を探します)。
他の人が言っているように、リフレクションは tpyes のメタデータのみを記述するため、役に立ちません。
ただし、Mono.Ceci l プロジェクトは、アセンブリ内の型の IL (中間言語) を実際に確認する実行時の方法です。Mono フレームワークの製品ですが、Microsoft CLR と互換性があります。
リフレクションを使用すると、検査するMethodBodyを提供するMethodBase.GetMethodBodyを介してメソッドの本体を検査できます。
ただし、このレベルでは、バイト配列で生の IL を扱っているため、最初から最後まで分析して、外部メソッドの呼び出しとその動作などを見つける必要があります。
ですから、それはきれいでも簡単でもありませんが、確かに可能です。
リフレクションでは、メンバーの本文は検査できず、署名のみを検査できます。言い換えれば、特定のメソッドやプロパティが何をするかについては何も教えてくれません。それがどのように見えるかだけです。
目的を達成するには、コンパイル済みの .dll または .exe を IL に変換するなどの方法を使用する必要があります。その後ildasm.exe
、IL を調べて、異議を唱えるものが何か実行されているかどうかを確認します。