NUnit says: An attempt was made to load a program with an incorrect format

  • Thread starter Thread starter colin.mackay
  • Start date Start date
C

colin.mackay

I'm using NUnit to test my application but it is giving me odd error
messages that I have not seen before. I'm at a loss to think what
configuration change I have made that would break NUnit. (Or what
configuration changes I made at all) The application is new, so these
are new unit tests fixtures. I also upgraded to NUnit 2.2.7 in case
there was a problem with the previous version (no luck). My application
runs okay if I launch it, yet I cannot test it.

Here is the message produced by using the NUnit console through
TestDriven.NET:
------ Test started: Assembly: NOsm.Dao.Testing.dll ------

TestCase 'M:NOsm.Dao.Testing.BookmarkDaoTest.SimpleTest'
failed: Could not load file or assembly 'NOsm.Dao.Testing' or one of
its dependencies. An attempt was made to load a program with an
incorrect format.
System.BadImageFormatException: Could not load file or assembly
'NOsm.Dao.Testing' or one of its dependencies. An attempt was made to
load a program with an incorrect format.
File name: 'NOsm.Dao.Testing'
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint,
StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
at TestDriven.TestRunner.AdaptorTestRunner.Run(ITestListener
testListener, ITraceListener traceListener, String assemblyPath, String
testPath)
at TestDriven.TestRunner.ThreadTestRunner.Runner.Run()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value
[HKLM\Software\Microsoft\Fusion!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
[HKLM\Software\Microsoft\Fusion!EnableLog].



0 passed, 1 failed, 0 skipped, took 0.89 seconds.


The code for SimpleTest is:
[Test]
public void SimpleTest()
{
Assert.IsFalse(true);
}

If I use the NUnit GUI I get a slightly different exception:
System.IO.FileNotFoundException...

Server stack trace:
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint,
StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
at System.AppDomain.Load(String assemblyString)
at NUnit.Core.Builders.TestAssemblyBuilder.Load(String assemblyName)
at NUnit.Core.Builders.TestAssemblyBuilder.Build()
at NUnit.Core.Builders.TestAssemblyBuilder.Build(String testName)
at NUnit.Core.TestSuiteBuilder.Build(String assemblyName, String
testName)
at NUnit.Core.SimpleTestRunner.Load(String assemblyName, String
testName)
at NUnit.Core.SimpleTestRunner.Load(String assemblyName)
at NUnit.Core.ProxyTestRunner.Load(String assemblyName)
at NUnit.Core.ProxyTestRunner.Load(String assemblyName)
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.PrivateProcessMessage(RuntimeMethodHandle
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(String assemblyName)
at NUnit.Util.TestDomain.Load(String assemblyFileName, String
testFixture)
at NUnit.Util.TestLoader.LoadTest(String testName)

Any help would be appreciated.

Thanks,
Colin.
 
I've seen this with v2.1 of nunit (we're goign back a few years). From
memory I seem to recall that I had a static function in one of my test
fixtures that was throwing an exception before the actual tests were
run by nunit.

You might want to temporarily bypass running via nunit gui and create
your own app that references the unit test assembly and run of of your
tests by specifically invoking it.

Alternatively I've also found it handy to run my test app from Visual
Studio (launching unit-gui.exe) but going to Debug | Exceptions and
setting "Break into the debugger" when any excpetion is thrown - so I
know exactly when any expecption is thrown - hanlded or not. sorry if
I repeatign stuff you already knwo but it can be quite handy

Jason
 
One other thing...are all referenced DLLs in the same folder as your
test dll. It looks as though a referenced assembly is missing and
can't be loaded at runtime.

Are you using any COM+ components anywhere in your project that is
being loaded somewhere ar tuntime before the tests? Are they
registered correctly?

You could use a Setup project to determine all true dependancies and
copy all into your debub/bin folder and then remove files selectively.

On my previous post, I was refering to setting Common Language Runtime
Exceptions to break on all exceptions

Jason
 
Okay - I've tracked down the problem. Somehow or another the project
properties for the testing assembly were set to build for a 64-bit
platform. I'm not sure how that happened - but it's fixed now.

Regards,
Colin.
 
Thanks for your assistance. Don't worry about repeating stuff I already
know. I could have missed something obvious that I had some sort of
mental block on. Before compilers gave really useful error messages you
can't believe the number of times I, or a collegue, could stare at a
piece of code trying to figure out why the compiler spat out the code
only to realise 2 hours later there was a missed semi-colon or other
obvious thing.

The reason in the end was a project property that had been set to build
for x64 for some reason. I set it back to the default of "Any CPU" and
it worked fine.

Regards,
Colin.
 
Back
Top