System.IO.FileNotFoundException when Platform target is not Any CPU

[Robert Dzikowski]

I am using Windows 7 64 bit, Visual Studio 2010, GUI runner, NUnit 2.5.4.10098.

When I compile any program with Build option Platform target set not to Any CPU
(Platform target is not Any CPU) then I get this 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.Reflection.Assembly.Load(String assemblyString)
   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.Util.TestLoader.LoadTest(String testName)

[Charlie Poole (charlie.poole)]

If you compile for x86, then you should run nunit-x86.exe. If you
compile for any other target
then nunit.exe should do the job. Can you list the combinations of
target and executable
for which you see this problem?

Charlie

On Mon, Apr 19, 2010 at 1:41 PM, Robert Dzikowski <email address hidden> wrote:
> Public bug reported:
>
> I am using Windows 7 64 bit, Visual Studio 2010, GUI runner, NUnit
> 2.5.4.10098.
>
> When I compile any program with Build option Platform target set not to Any CPU
> (Platform target is not Any CPU) then I get this 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.Reflection.Assembly.Load(String assemblyString)
>   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.Util.TestLoader.LoadTest(String testName)
>
> ** Affects: nunitv2
>     Importance: Undecided
>         Status: New
>
> --
> System.IO.FileNotFoundException when Platform target is not Any CPU
> https://bugs.launchpad.net/bugs/566907
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

[Robert Dzikowski (rdzikowski-gmail)]

I see this problem only when Platform target is set to something different then Any CPU.

[Charlie Poole (charlie.poole)]

We still need to know if you are running nunit.exe or nunit-x86.exe...

[Charlie Poole (charlie.poole)]

Also... what is being compiled for another target? The test? The program under test? Without the detail, it's not possible to repro the problem.

[Robert Dzikowski (rdzikowski-gmail)]

I run GUI runner, I don't know if it is nunit.exe or nunit-x86.exe.

To reproduce this problem:
1. make new console app in Visual Studio 2010,
2. Chose Debug configuration (which is chosen by default)
3. On Build tab chose Platform target different than Any CPU
4. Compile this app
When you open this app in NUnit GUI runner you will get the above exception.

BTW when .Net 4.0 is chose as a target framework you get the following exception:
System.NullReferenceException...

Server stack trace:
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.RemoteTestAgent.AgentRunner.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.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

[Robert Dzikowski (rdzikowski-gmail)]

I run nunit.exe

[Charlie Poole (charlie.poole)]

In that case, if you are debugging an x-86 program on a 64-bit OS, you
_will_ see the error.
NUnit.exe is IL only and therefore runs as 64 bit on an 64-bit OS.
NUnit-x86 is provided to
take care of this problem.

However, I would not expect to see this particular problem when
testing an x-64 target.

It sounds like you are also having the additional problem with .NET
4.0 that was discussed
in two separate bugs. The 2.5.4 NUnit release will not run tests under
the final release
(or the RC) of .NET 4.0 unless you force nunit itself to run under
that release. This is
already fixed in 2.5.5, which I will be releasing this week.

Charlie

On Tue, Apr 20, 2010 at 6:57 AM, Robert Dzikowski <email address hidden> wrote:
> I run nunit.exe
>
> --
> System.IO.FileNotFoundException when Platform target is not Any CPU
> https://bugs.launchpad.net/bugs/566907
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

[Robert Dzikowski (rdzikowski-gmail)]

When Platform target is x64, I get the following exception:

System.ArgumentOutOfRangeException...
   at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
   at NUnit.Util.RuntimeFrameworkSelector.SelectRuntimeFramework(TestPackage package)
   at NUnit.Util.TestRunnerFactory.MakeTestRunner(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

[Charlie Poole (charlie.poole)]

Ah ha! So we may have a different problems for x64. The stack trace
and an examination
of the code suggest that our parsing of the PE header is not working
for an x64 assembly.

Can you post a small assembly that exhibits this problem? I can create
one myself, but
it's probably best to use one created in your environment.

Charlie

On Tue, Apr 20, 2010 at 7:54 AM, Robert Dzikowski <email address hidden> wrote:
> When Platform target is x64, I get the following exception:
>
> System.ArgumentOutOfRangeException...
>   at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
>   at NUnit.Util.RuntimeFrameworkSelector.SelectRuntimeFramework(TestPackage package)
>   at NUnit.Util.TestRunnerFactory.MakeTestRunner(TestPackage package)
>   at NUnit.Util.TestLoader.LoadTest(String testName)
>
> --
> System.IO.FileNotFoundException when Platform target is not Any CPU
> https://bugs.launchpad.net/bugs/566907
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

[Robert Dzikowski (rdzikowski-gmail)]

Here you are x64 assembly, requires .Net 3.5

[Charlie Poole (charlie.poole)]

Thanks... I'm working on a fix and I'll use this to verify it.

The problem is that NUnit's AssemblyReader class assumes PE32 format, while x64
binaries use PE32+ format. There are a few differences in the offsets and some
data element sizes.

This has gone unnoticed while AssermblyReader was only used to check for version
information after a failure to load and also in the Tools | Test
Assemblies... display
of the gui. But with 2.5.4, it is used for every assembly loaded
unless you select the
framework explicitly in the nunit project, through the gui or via the
command line.

Combined with our .NET 4.0 problem, this can make 2.5.4 unusable for
some people.

Best workaround I know is to create shortcuts that force NUnit to run under the
specific CLR you will use for testing and _also_ specify the framework to use.
Or use 2.5.3 for now. I'll release 2.5.5 as soon as this bug is fixed.

Charlie

On Tue, Apr 20, 2010 at 9:43 AM, Robert Dzikowski <email address hidden> wrote:
> Here you are x64 assembly, requires .Net 3.5
>
> ** Attachment added: "NunitBug.exe"
>   http://launchpadlibrarian.net/44908176/NunitBug.exe
>
> --
> System.IO.FileNotFoundException when Platform target is not Any CPU
> https://bugs.launchpad.net/bugs/566907
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

[Charlie Poole (charlie.poole)]

Robert...

I seem to have a fix. After some refactoring, I'd like to post it for you to try. Do you prefer an msi or a zip?

Charlie

[Robert Dzikowski (rdzikowski-gmail)]

zip please

[Charlie Poole (charlie.poole)]

It's here... http://nunit.org/downloads/NUnit-2.5.4.10110-dbg.zip

[Robert Dzikowski (rdzikowski-gmail)]

I tested it with x64 assembly, it works.

BTW you were right, for running tests for x86 assembly I have to run nunit-x86.exe.

[Charlie Poole (charlie.poole)]

Thanks for testing it.

Yes, nunit-x86 was created as a "feature" but it now feels like a
limitation. I want to think
about spawning an x86 process automatically when nunit is running as a
64 bit process.

Charlie

On Wed, Apr 21, 2010 at 5:30 AM, Robert Dzikowski <email address hidden> wrote:
> I tested it with x64 assembly, it works.
>
> BTW you were right, for running tests for x86 assembly I have to run
> nunit-x86.exe.
>
> --
> System.IO.FileNotFoundException when Platform target is not Any CPU
> https://bugs.launchpad.net/bugs/566907
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>