Re: Unmanaged DLL staying loaded in NUnit GUI

I  thought of that. I let ReSharper run my tests for me, and have never
had a problem, but my colleague uses TestDriven.NET, or the NUnit GUI,
and he has this problem all day long. I notice that CheckBox for "Enable
Shadow Copy" (in the NUnit GUI for .NET 2.0) is not used anywhere in the
code (see attached), which is to say, you can check and uncheck that
option all day long, to no effect. That can't be right.
 
In any case, I've never changed the default .config for the NUnit GUI,
which includes <appSettings><add key="shadowfiles.path"
value="%temp%\nunit20\ShadowCopyCache" />, so I would expect the GUI to
use the cache...
 
...and it does: for managed DLLs! The CLR does not copy unmanaged DLLs
to the cache. There's actually misinformation about this at certain MSDN
blogs; bloggers refer to unmanaged DLLs being loaded "into an
AppDomain." There's no such thing. After running NUnit in the debugger,
I can see that the AppDomain for the previous test run is not unloaded
until just before the next one, but even if I were to change my code to
use "dynamic P/Invoke," I'd have no way of knowing that I could call
FreeLibrary() anytime before the process exits.
 
I don't see how NUnit could "release" unmanaged DLLs that it's
indirectly loaded, nor how it could somehow let my code know that it can
do so. So this is a problem I'll have to live with.

________________________________

	From: Nick Walker [mailto:[email protected]] 
	Sent: Friday, December 21, 2007 4:52 AM
	 
	...
	  
	I think this is to do with the Enable Shadow Copy option on the
Tools|Options page.  If ticked, this option causes the whole "EXE
folder" to be copied to a temp folder before being run.  This is so that
when you go back to recompiling your module, it's not being "blocked" by
the Nunit app, stopping VS from updating the DLL.  If cleared, then the
app is run in its normal folder but Nunit loads (and blocks) the DLL,
resulting in the error seen.  If your DLL is loading data from a file
that must reside in the EXE folder then you'll need to have it cleared
but otherwise try it set and see if it sorts out your problem.
	 
	This is the only aspect of Nunit I feel I can answer on with any
authority whatsoever so I hope this turns out to be of use.  If it turns
out that you've got this option set already then I've probably got it
wrong :-(
	 
	 
	Nick Walker

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

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