2

大規模な F# プロジェクトをリファクタリングしました。F# コンパイラの 1 回の長時間実行ですべてのソース ファイルをコンパイルする、自動化された buildcommand があります。これは、再現可能なビルドを簡単に実行できるようにするためです。buildcommand は、プロジェクトをビルドする前にそれ自体で nunit-console を実行しますが、これはうまくいきます。リファクタリングの後、ユニット テストの大部分が失敗し始めました。

例外: System.BadImageFormatException: 不正な形式のプログラムを読み込もうとしました。(HRESULT からの例外: 0x8007000B)

これは、プロジェクトが F# 2.0 でコンパイルされた場合で、コマンド ラインから (つまり、NUnit を使用せずに) 同じ問題を再現できます。スタック トレースは、多くの場合、無害な新しいコード (明らかなことを何もせずにデータを格納するだけのコンストラクター) を指しています。

ただし、プロジェクトが F# 3.0 を使用してコンパイルされると、F# 2.0 で問題が発生し、私が試したすべての単体テストがパスしました。これは、コマンド ラインから呼び出された場合です (NUnit を使用していません)。NUnit は、私が手動で呼び出すことができる新しくコンパイルされた実行可能ファイルが存在しないと主張しています。上部にファイルが見つからない例外を含む長いスタック トレースがあります。(私は F# 3.0 を使用して buildcommand をビルドしようとはしていないので、その単体テストがまだうまくいっているのは当然のことです)。

Google は、HRESULT: 0x8007000B はコンパイラのバグが原因である可能性があることを示唆しています。悪い職人が自分のツールを非難しているケースかもしれませんが、F# 3.0 を使用すると問題はなくなります。F# 2.0 で再び機能するようにするために何か提案してもらえますか?

F# 3.0 の使用については、それほど問題はありません。しかし、私は本当に NUnit が必要です。誰が何がうまくいかないのか知っていますか？繰り返しますが、Nunit は、コマンド ラインから起動したときに正常に実行される実行可能ファイルの読み込みに失敗しますが、F# 3.0 ではなく F# 2.0 を使用してコンパイルされた場合、同じ実行可能ファイルを同じ場所から正常に読み込みます。

これについての助けに本当に感謝します。どうもありがとう。

4

2 に答える 2

0

32 ビット アセンブリを 64 ビット プロセスで読み込もうとした場合 (またはその逆) にも、このエラー メッセージが表示されると思います。何Platform Targetを使用してプロジェクトをコンパイルしていますか (プロジェクト プロパティ ペインの [ビルド] タブで設定)。

私の推測では、プロジェクト設定またはその他の構成ファイルに混乱があり、F# 2.0 コンパイラが間違ったプラットフォーム ターゲット用にコンパイルする原因になっていると思われます。NUnit がアセンブリをロードしようとすると、NUnit アセンブリとは異なる「ビット数」があり、32 ビット システムと 64 ビット システム用の特定のバージョンがあると思われますが、最終的にクラッシュします。

于 2012-08-10T19:00:43.147 に答える
0

これは、バインド リダイレクトの問題である可能性があります。NUnit を呼び出すとき、単に DLL/EXE を渡しますか、それとも .nunit ファイルを渡しますか? いずれの場合も、VS2012 の新しい ConsoleApplication プロジェクトで取得したものと同じバインディング リダイレクトを持つ対応する .config ファイルがあることを確認します (たとえば、Powerpack が依存するため、FSharp.Core 2.0.0.0 -> 4.3.0.0 をリダイレクトするもの)。前者ですが、VS2012 ボックスには後者があります)。

于 2012-08-10T19:26:36.440 に答える