我重构了一个大型的F＃项目。它有一个自动构建命令，可以在一个长期的F＃编译器中编译所有源文件。这样我就可以轻松地进行可重现的构建。构建命令在构建项目之前运行nunit-console，这很好。重构后，我的大部分单元测试开始失败：
异常：System.BadImageFormatException：尝试加载程序 格式不正确。 （HRESULT异常：0x8007000B）
这是用F＃2.0编译项目时，我可以从命令行重现相同的问题（即不使用NUnit）。堆栈跟踪经常指向一段无用的新代码（一个只存储一些数据的构造函数，而不会对它做任何明显的事情）。
但是，当使用F＃3.0编译项目时，所有在F＃2.0下遇到问题的单元测试和我尝试通过。这是从命令行调用时（不使用NUnit）。 NUnit现在声称可以手动调用的新编译的可执行文件不存在。顶部有一个很长的堆栈跟踪，文件未找到异常。 （我还没有尝试使用F＃3.0构建构建命令，所以它的单元测试仍然没问题也就不足为奇了。）
谷歌建议HRESULT：0x8007000B可能是由编译错误引起的。这可能是一个糟糕的crasftsman责备他的工具的情况，但是当使用F＃3.0时问题就消失了。有人可以建议任何事情来尝试让事情在F＃2.0下再次运作吗？我对使用F＃3.0并不太感到困扰。但我真的需要NUnit来工作。有谁知道会出现什么问题？重申一下，Nunit无法加载从命令行启动时运行正常的可执行文件，但在使用F＃2.0而不是使用F＃3.0编译时，从同一位置加载相同的可执行文件。
如果有任何帮助，我将非常感激。非常感谢。
答案 0 :(得分：0)
如果您尝试在64位进程中加载32位程序集（反之亦然），我相信您也会收到此错误消息。您使用（通过项目属性窗格的“构建”选项卡设置）编译项目的Platform Target是什么？
我的猜测是项目设置或其他配置文件中存在一些混淆，导致F＃2.0编译器为错误的平台目标编译它。当NUnit尝试加载程序集时，它具有与NUnit程序集不同的“位数” - 我相信它具有32位和64位系统的特定版本 - 并最终崩溃。
答案 1 :(得分：0)
这闻起来可能是绑定重定向问题。当你调用NUnit时，你只是将DLL / EXE传递给它，还是传递一个.nunit文件？在任何一种情况下，确保有一个相应的.config文件，其中包含与VS2012中新的ConsoleApplication项目相同的绑定重定向（例如重定向FSharp.Core 2.0.0.0 - > 4.3.0.0的那些，因为powerpack取决于在前者，而你的VS2012盒子上有后者。）