実行時にアセンブリをビルドするために使用する場合Reflection.Emit
、ディスクに保存する前にアセンブリのMSILを確認したいと思います。PEVerifyと同様ですが、実行時です。そのようなAPIはありますか?
4 に答える
peverify.exeはc:\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ peverify.dll(またはc:\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ peverify.dll)のフロントエンドのようですネイティブDLLであるCLR2.0の場合)(実際には、peverify.exeもネイティブです)
これはどこにも文書化されていないので、おそらくパブリックAPIではありません。Dependency Walkerのようなものを使用して、そのDLLからエクスポートされた関数を理解できる場合がありますが、peverify.exeを呼び出す方が簡単だと思います。
編集:事例証拠:
- コンパイラのステップで、Booは実際にpeverify.exeを呼び出します。
- Nemerleは、テストでpeverify.exeを呼び出します。
- Castle.DynamicProxyは、テストでpeverify.exeを呼び出します。
PEVerifyを使用する代わりに、ここで説明するように、インプロセスソリューションにILSpyの逆コンパイラーを使用できます:http://www.codeproject.com/Tips/659692/Automated-MSIL-PE-verification-using-ILSpy
記事の要約は次のとおりです。
- テストプロジェクト、またはこの場合はランタイムILチェッカーから参照する関連DLLを収集します
- メソッドを繰り返し、Mono.Cecilを使用して検証します
- メソッドごとに、検証を実行するICSharpCode.Decompilerで定義されているAstBuilderに追加します。例えば。
var context = new DecompilerContext(method.Module) { CurrentType = method.DeclaringType };
var astBuilder = new AstBuilder(context);
astBuilder.AddMethod(method);
パフォーマンスに関しては、どちらの方法が速いかは確認していません。この方法は進行中ですが、ILの検証時に抽象構文ツリーが構築されるため、処理が遅くなる可能性があります(この理論を確認するには、パフォーマンステストを設定する必要があります)。
上記の記事で指摘したように、ILSpyデコンパイラはPEVerifyよりも信頼性が高いことがわかりました。ある例では、PEVerifyは1つのアセンブリが有効であると宣言しましたが、ILSpyは生成中のエラーを示す美しいスタックトレースを正しく提供しました。
LCGをデバッグすると、Windbgを使用して実行時に生成されたコードをデバッグできます。
多分それはあなたを助けることができます。
peverifyを呼び出すことは確かにおそらく最良のアプローチですが、peverifyは、実行中の.NETのバージョンに応じて多くの異なるディレクトリにあります。これらすべてのパスを列挙して最新のパスを確認することもできますが、これは最後にIIRCをカウントしたときに少なくとも6つの異なるパスであり、クロスプラットフォームではありません。モノは含まれていません。
最近、Microsoft.Build.Tasksアセンブリにリンクしてから、Microsoft.Build.Tasks.GetFrameworkSdkPathのインスタンスを作成し、Pathプロパティを呼び出すことができることを発見しました。私が気付いた奇妙な振る舞いの1つは、最初にパスにアクセスすると例外がスローされることですが、その例外を飲み込むだけで、それ以降はパスにアクセスできます。
その場合、Peverify.exeはPath.Combine(new GetFrameworkSdkPath()。Path、 "bin \ peverify")になります。