Re: NUnit and VS2005 Project Files

What I have ended up doing about this issue is to simply create a test
config
for every config found in the VS Project. If it's there, I assume the user 
created it for some good reason. This seems like the safest course. If
the user tries to run tests for a particular config that doesn't match
the current environmet, they may not run successfully.
 
Charlie


  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Gary
Evans
Sent: Tuesday, February 26, 2008 12:47 PM
To: [email protected]
Subject: Re: [nunit-developer] NUnit and VS2005 Project Files


> Date: Mon, 25 Feb 2008 09:42:59 -0800
> From: "Charlie Poole" <[email protected]>
> Subject: Re: [nunit-developer] NUnit and VS2005 Project Files
> To: <[email protected]>
> Message-ID: <008001c877d5$e17a30c0$6401a8c0@ferrari>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Daniel, 
> 
> > ASSuming the following:
> > 
> > NUnit is a .Net application.
> 
> Indeed. And designed to test other .NET applications.
> 
> > .Net is designed to be CPU independant. It relies on the CLR 
> > which can be written for any CPU.
> 
> Yes.
> 
> > Does it make sense to build a .Net application for any 
> > platform besides "Any CPU?"
> 
> Apparently yes, given that people are doing it and Visual Studio
> supports it. But, frankly, I don't quite understand it either.
> 
> I do know that for C#, the only difference between x86, x64, IA-64
> and AnyCPU is a flag in the header of the assembly. That flag is
> used to determine which CLR will be used to run the assembly and
> subsequently which GAC will be searched for references. For C++
> mixed assemblies, of course, the difference would be more significant,
> but that's not what this particular bug is about.
> 
> So what I'm looking for here is a better understanding of what
> people are doing and why, since NUnit has to support what its
> users are doing.
> 
> So, can anyone shed light on this?
> 
> Charlie
> 

I worked on 32 bit and 64 bit versions of an app at work, and we built our
assemblies as 32 bit or 64 bit...
We had an app which interfaced with unmanaged dlls which only worked in 32
bit.
 
Anyway, we marked our managed .exe as 32 bit to ensure that it ran as a 32
bit process when running on 64 bit Vista (if we'd left the exe as AnyCPU it
would have ran as a 64 bit, and failed when interfacing with the 32 bit
unmanaged assembly).
 
Another case I can think of (but haven't tried)... I was reading an article
where it mentioned that the F# compiler performs tailcall optimisation, as
does the 64 bit C# JIT compiler, but the 32 bit one doesn't
(http://blogs.msdn.com/jomo_fisher/archive/2007/09/19/adventures-in-f-tail-r
ecursion-in-three-languages.aspx) meaning that an code will run fine on a 64
bit machine, but stack overflow on a 32 bit machine.
 
I can't imagine a scenario to take advantage of this, but you might want to
build an optimised 64 bit version of an assembly marked as x64 that takes
advantage of tail code recursion, and mark it as x64 so it doesn't
inadvertently run on 32 bit, and have an alternate AnyCPU built version? 
 
You might also have different x86/x64 assemblies that contain PInvokes for
interop - you'd want to mark them explicitly as win32/x64?
 
Erm, don't know if that's given any ideas? I can't think of any general
reason why you wouldn't build as AnyCPU for a pure .NET assembly.
 
Cheers,
Gary
 
 


  _____  

Think you know your TV, music and film? Try Search Charades!
<https://www.searchcharades.com>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
nunit-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-developer