Loading...

nunit-discuss@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

[nunit-discuss] Re: Only can run entire suite of tests on 2.6 nickdu Tue Apr 10 18:00:20 2012

I believe I found the cause of the error.  I have a class defined in
the Common assembly (the assembly that the appdomain says it can't
load which is in the same directory as my NUnit test assembly) which
derives from ILogicalThreadAffinitive.  I have this class deriving
from ILogicalThreadAffinitive so that the class can flow across
threads in a call chain.  The problem is that in NUnit we have a
process with multiple appdomains with different application base
directories so that when a call flows from the appdomain that the
NUnit test assembly is loaded calls into the other appdomain which
doesn't have the application directory set to the directory where the
NUnit test assembly exists, it can't load the Common assembly.

Thanks,
Nick

On Apr 5, 3:41 pm, nickdu <[EMAIL PROTECTED]> wrote:
> The first thing I did was to create a console application which
> references the assembly that contains the tests and it calls the Lock
> Test3 and Test5.  These are minimum set of tests I would run from
> NUnit GUI from choosing the Lock class that would fail.  From my
> console app they both ran fine.  Here is my console application:
>
> using System;
> using Redbone.Framework.BusinessProcess.Tests;
>
> public class Application
> {
>         public static void Main()
>         {
>                 try
>                         {
>                         Lock @lock = new Lock();
>                         @lock.Test3();
>                         @lock.Test5();
>                         Console.WriteLine("Completed both tests 
> successfully.");
>                         }
>                 catch(Exception e)
>                         {
>                         Console.WriteLine(e.ToString());
>                         }
>         }
>
> }
>
> Now I'll try to come up with a minimum set of code which fails in
> NUnit GUI which I could send out to others.
>
> By the way, here is the details of the exception the debugger gave me
> when the exception was thrown in the nunit-agent:
>
> System.TypeInitializationException occurred
>   Message=The type initializer for '<Module>' threw an exception.
>   Source=Redbone.Framework.BusinessProcess
>   TypeName=<Module>
>   StackTrace:
>        at
> Redbone.Framework.BusinessProcess.ProcessService.Start(XmlQualifiedName
> name, String description, Version version, String step, String key,
> IRow row)
>        at Redbone.Framework.BusinessProcess.Tests.Lock.Test5() in C:
> \data\development\Redbone\bpf\Tests\Lock.cs:line 76
>   InnerException: System.TypeInitializationException
>        Message=The type initializer for '<Module>' threw an exception.
>        Source=ssoDotNet
>        TypeName=<Module>
>        StackTrace:
>             at
> <CrtImplementationDetails>.ThrowModuleLoadException(String ,
> Exception )
>             at
> <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
>             at .cctor()
>        InnerException: <CrtImplementationDetails>.ModuleLoadException
>             Message=The C++ module failed to load while attempting to
> initialize the default appdomain.
>
>             Source=msvcm90
>             StackTrace:
>                  at
> <CrtImplementationDetails>.ThrowModuleLoadException(String
> errorMessage, Exception innerException)
>                  at
> <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
>                  at .cctor()
>             InnerException:
> System.Runtime.Serialization.SerializationException
>                  Message=Unable to find assembly
> 'Redbone.Framework.BusinessProcess.Common, Version=4.0.0.0,
> Culture=neutral, PublicKeyToken=e3fe5053ddfa671d'.
>                  Source=mscorlib
>                  StackTrace:
>                    Server stack trace:
>                       at
> System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssemb­ly()
>                       at
> System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryA­ssemblyInfo
> assemblyInfo, String name)
>                       at
> System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String
> objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA,
> Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader
> objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo,
> SizedArray assemIdToAssemblyTable)
>                       at
> System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWit­hMapTyped(BinaryObjectWithMapTyped
> record)
>                       at
> System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
>                       at
> System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(Hea­derHandler
> handler, __BinaryParser serParser, Boolean fCheck, Boolean
> isCrossAppDomain, IMethodCallMessage methodCallMessage)
>                       at
> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(­Stream
> serializationStream, HeaderHandler handler, Boolean fCheck, Boolean
> isCrossAppDomain, IMethodCallMessage methodCallMessage)
>                       at
> System.Runtime.Remoting.Channels.CrossAppDomainSerializer.DeserializeObject­(MemoryStream
> stm)
>                       at
> System.Runtime.Remoting.Messaging.SmuggledMethodCallMessage.FixupForNewAppD­omain()
>                       at
> System.Runtime.Remoting.Channels.CrossAppDomainSink.DoDispatch(Byte[]
> reqStmBuff, SmuggledMethodCallMessage smuggledMcm,
> SmuggledMethodReturnMessage& smuggledMrm)
>                       at
> System.Runtime.Remoting.Channels.CrossAppDomainSink.DoTransitionDispatchCal­lback(Object[]
> args)
>                    Exception rethrown at [0]:
>                       at
> System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
> reqMsg, IMessage retMsg)
>                       at
> System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
> msgData, Int32 type)
>                       at System.AppDomain.get_Id()
>                       at
> <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr function,
> Void* cookie)
>                       at
> <CrtImplementationDetails>.DefaultDomain.Initialize()
>                       at
> <CrtImplementationDetails>.LanguageSupport.InitializeDefaultAppDomain(Langu­ageSupport*
>  )
>                       at
> <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* )
>                       at
> <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
>                  InnerException:
>
> Our framework makes use of SSO, some managed TIBCO assemblies.  The
> SSO assemblies in turn have implicit links to unmanaged assemblies.
> These assemblies are in a directory which are in the path.  I had a
> breakpoint on ProcessService.Start() but it never hit that.  It shows
> Start() at the top of the exception stack.  My guess is that when the
> call was attempted it started to jit the code for Start() and that's
> where it ran into a problem.
>
> Thanks,
> Nick
>
> On Apr 4, 11:47 am, nickdu <[EMAIL PROTECTED]> wrote:
>
>
>
> > I'm going to put some effort in today to get a simple repro of this.
> > I hope I'm successful.  By the way, I tried 2.5.10 and the same issue
> > occurs so it's not specific to 2.6.
>
> > Thanks,
> > Nick
>
> > On Apr 2, 5:09 pm, Charlie Poole <[EMAIL PROTECTED]> wrote:
>
> > > That would help. I'd definitely like to see it.
>
> > > Regarding dependencies, I'd say that if running tests 1-4 has an
> > > effect on test 5, that's a dependency by definition. It's just one that
> > > we don't yet understand and which is probably due to the underlying
> > > platform - or NUnit itself - rather than something you coded explicitly.
>
> > > Charlie
>
> > > On Mon, Apr 2, 2012 at 12:43 PM, nickdu <[EMAIL PROTECTED]> wrote:
> > > > Yeah, I'm thinking about spending a little bit of time to create a
> > > > skelaton of our framework that has the same dependent assemblies to
> > > > see if I can repro and if so send it along or post the code.
>
> > > > With respect to test dependencies, I don't think this could be the
> > > > case.  As I said, I can start NUnit GUI fresh and run Lock Test5
> > > > without a problem, and therefore it's not dependent on running any
> > > > other tests.  However, if I start NUnit GUI fresh and select the Lock
> > > > 'set' of tests and run them then Test1 - Test4 succeed and Test5 -
> > > > Test8 succeed.
>
> > > > Nick
>
> > > > On Apr 2, 12:54 pm, Charlie Poole <[EMAIL PROTECTED]> wrote:
> > > >> Hi Nick,
>
> > > >> On Mon, Apr 2, 2012 at 6:04 AM, nickdu <[EMAIL PROTECTED]> wrote:
> > > >> > There were trace files created with trace information in them, just
> > > >> > none of it seemed to point to a reason for the issue I'm having.
>
> > > >> Right - that's what I meant. NUnit is simply considering your
> > > >> problem as a test failure, not an NUnit problem worthy of logging.
>
> > > >> > I don't have any automatic reload setting turned on.
>
> > > >> OK
>
> > > >> > When I mentioned loading it was more about how NUnit loads a class 
> > > >> > and/
> > > >> > or method in order to execute it.  It seems odd that if I select the
> > > >> > Lock class and run I get different behavior than when I choose each
> > > >> > Lock test method individually and run them.  My guess is that NUnit 
> > > >> > is
> > > >> > loading the code differently in those two cases.
>
> > > >> NUnit's "Loading" involves only your test assembly. It has to happen 
> > > >> before
> > > >> the tests can be displayed in the Gui. That loading is only repeated 
> > > >> if you
> > > >> use a reload item on the menu or if you have enabled automatic reload 
> > > >> on
> > > >> run or when the assembly changes.
>
> > > >> Loading of dependent assemblies happens according to normal .NET rules,
> > > >> as the code is jitted and executed. Again, once a dependent assembly is
> > > >> loaded into the test AppDomain, it stays there.
>
> > > >> So, your problem arises when the dependent assembly is first needed by
> > > >> one of the Lock tests. If you have run some other test first, which 
> > > >> successfully
> > > >> loads the assembly, then the Lock tests have no problem. This is 
> > > >> exactly
> > > >> the sort of inter-test dependency I was originally writing about - not
> > > >> necessarily
> > > >> a dependency that you intentionally created, but one that exists 
> > > >> nevertheless.
>
> > > >> I guess that gives you two possible attacks on the problem:
> > > >> 1. Trace how and why the Lock class cannot load the assembly.
> > > >> 2. Trace how and why the complete class is able to load the assembly.
>
> > > >> What's different in these classes?
>
> > > >> Charlie
>
> > > >> PS: Feel free to post some code if it doesn't expose any company 
> > > >> secrets.
>
> > > >> > Thanks,
> > > >> > Nick
>
> > > >> > On Apr 1, 6:08 pm, Charlie Poole <[EMAIL PROTECTED]> wrote:
> > > >> >> Well, the absence of trace info from NUnit at least tells us that 
> > > >> >> NUnit is
> > > >> >> not aware of any problem. I guess we knew that though.
>
> > > >> >> Regarding loading: NUnit does not reload any tests unless you tell 
> > > >> >> it to.
> > > >> >> You should probably turn off any automatic reload settings if you 
> > > >> >> have
> > > >> >> them set. That way you can manually control when a reload takes 
> > > >> >> place.
>
> ...
>
> read more »

-- 
You received this message because you are subscribed to the Google Groups 
"NUnit-Discuss" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/nunit-discuss?hl=en.