Re: Unmanaged DLL staying loaded in NUnit GUI

Hi Anthony,
 
Does ReSharper run tests in a separate process? If so, that would explain
the discrepancy.
 
You're right that NUnit has nothing to do with loading and unloading of
assemblies.
 
Regarding the ShadowCopy Gui thing - that's a bug for sure. It's a case of
losing the
connection between the gui and the actual settings when I changed the format
of the settings dialog.
 
Charlie

  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Nassar,
Anthony
Sent: Friday, December 21, 2007 10:13 AM
To: [email protected]
Subject: Re: [Nunit-users] 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