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