Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
295 views
in Technique[技术] by (71.8m points)

c# - System.BadImageFormatException caused by NUnit project

Good day everyone. I have been having the same problem all day at work and am struggling to find any new paths to go down.

I am getting the following error when my solution builds on server. I have no problem running/debugging all tests in the solution and it builds fine. Both server and my PC are x64. I have followed a lot of advice which I have found to no avail.

I have set Platform Target to x86 for all projects in my solution under all configurations.

I am aware that there is an nunit-console-x86.exe which could make all the difference but I'm not sure where to specify this in the code.

Please realise I have trail-blazed the internet, so apologies if I have missed something.

System.BadImageFormatException: Could not load file or assembly
'Spin.TradingServices.DataAcquisition.Test.NUnit, Version=1.0.12103.2060, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'Spin.TradingServices.DataAcquisition.Test.NUnit, Version=1.0.12103.2060, Culture=neutral, PublicKeyToken=null'

Server stack trace: at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.Assembly.Load(AssemblyName assemblyRef) at NUnit.Core.Builders.TestAssemblyBuilder.Load(String path) at NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites) at NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites) at NUnit.Core.TestSuiteBuilder.BuildSingleAssembly(TestPackage package) at NUnit.Core.TestSuiteBuilder.Build(TestPackage package) at NUnit.Core.SimpleTestRunner.Load(TestPackage package) at NUnit.Core.ProxyTestRunner.Load(TestPackage package) at NUnit.Core.ProxyTestRunner.Load(TestPackage package) at NUnit.Core.RemoteTestRunner.Load(TestPackage package) at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs) at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at NUnit.Core.TestRunner.Load(TestPackage package) at NUnit.Util.TestDomain.Load(TestPackage package) at NUnit.ConsoleRunner.ConsoleUi.Execute(ConsoleOptions options) at NUnit.ConsoleRunner.Runner.Main(String[] args)

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLMSoftwareMicrosoftFusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLMSoftwareMicrosoftFusion!EnableLog].

http://app1017-build.oy.gb.sportingindex.com:8080/job/TradingServices.DataAcquisition-Dev/ws/DataAcquisition/build.proj(86,5): error MSB6006: "nunit-console.exe" exited with code -100. Done Building Project " (default targets) -- FAILED.

Build FAILED.

PLEASE NOTE: We have reverted our build on Hudson and now re-committing files more gradually. I will report back on how this goes. Tried get a few heads involved on this one to no avail unfortunately. Shame!

Update I haven't been back to this page for a while but it looks like there are lots of different solutions. If I could mark them all as the answer I would! Those of you finding your way here should probably give equal credit to each option.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

I had this problem with a console app on X64 pc, the build was set as x86 and it still crashed. I went into Properties on the Console App and under build I changed my Platform Target from x86 to Any CPU then suddenly all the tests worked and ran successfully.

of note, the Configuration Manager's platform field can "lie" to you and doesn't actually have to reflect what the project's properties are actually configured to do. My configuration manager said that "Common.dll" was being built as "Any CPU", but the project properties (the setting that really matters) was building it as "x86".

enter image description here


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...