Re: Unmanaged DLL staying loaded in NUnit GUI

"Nassar, Anthony" <[email protected]>
Newsgroups gmane.comp.windows.dotnet.nunit.user
Message-ID <[email protected]>
Yes, it does, though it never occurred to me to check that until you
asked. TaskRunner.exe shows up in the Task Manager when the tests start.

 
I didn't intend to register a complaint about NUnit w/r/t unmanaged
DLLs, but I thought it was important to document the problem. Short of
rewriting the GUI entirely, and running tests out of process, there's
nothing that can be done. 
________________________________

	From: Charlie Poole [mailto:[email protected]] 
	Sent: Friday, December 21, 2007 2:02 PM
	To: Nassar, Anthony; [email protected]
	Subject: RE: [Nunit-users] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.