Yup, we create a new appdomain and run everything in that. And that is the source of all these problems. The simplest way around this is to make sure that the nunit runner (gui or cmd line) is in the same directory as the unit test assembly and the assemblies being tested.
-----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 4:20 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Bizarre NUnit problem with delegates... On Wed, 24 Apr 2002 12:17:38 -0700, Gordon Weakliem <[EMAIL PROTECTED]> wrote: >We had seen a similar problem where the object being tested threw a custom exception defined in another assembly, and NUnit had problems loading the exception's assembly. It turned out that even though NUnit said that it couldn't load the exception's assembly, the real problem was that NUnitCore.dll wasn't in the path. The problem was fixed when the developer copied nunitcore.dll into the same directory as the other files. So it might be something worth trying to copy all your dlls into the same directory along with NUnitCore (or copy everything to program files\nunit\bin) and see if it works then. There's a bug report [1] on sourceforge that seems related. > >[1] http://sourceforge.net/tracker/index.php? func=detail&aid=505054&group_id=10749&atid=110749 > No such luck here -- NUnitCore is already in the same directory. Actually, it's interesting as to why this should be happening at all -- if I am right, NUnit probably creates a new AppDomain, loads the TestClass into it and executes the specified method.... Atul You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
