** Branch linked: lp:nunitv2
--
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/1167805
Title:
cross-domain problems with XmlSchema and call context
Status in NUnit V2 Test Framework:
Fix Committed
Bug description:
The problem is related to accessing AppDomain evidence in the child
(test) domain. This causes a hidden cross-domain call back to the main
domain, carrying along any call context data that can, then, not
deserialize in the main domain. The problem is somewhat similar, but
not identical or directly related, to another bug (#1084181)
The problem is not 100% solvable, but it's magnified by the fact that
certain seemingly benign system calls, such as XmlSchema.Read, access
the configuration system behind the scenes, which, when it's the first
access, accesses AppDomain evidence.
This problem has gotten worse in NUnit 2.6.2, as demonstrated below. I
have been experimenting a bit, and discovered an easy, albeit slightly
weird fix. The following test will always fail in NUnit 2.6.2, unless
another test which accessed the configuration system has run earlier
in the same run:
[Test]
public void XmlSchemaReadWithCallContext()
{
CallContext.SetData("mykey", new Data());
XmlSchema.Read(new StringReader(@"<xsd:schema
xmlns:xsd='http://www.w3.org/2001/XMLSchema'></xsd:schema>"), null);
}
where "Data" is any serializable class implementing
ILogicalThreadAffinative (it can be empty).
A solution is to make sure NUnit itself accesses the configuration
system in the test domain, before running any tests. This activates
some caching which prevents the evidence access from happening. A
simple line like this will suffice:
System.Configuration.ConfigurationManager.GetSection("dummy");
to be executed in the test domain, before anything is placed in the
call context.
Attached is a file containing some relevant tests. NUnit 2.5.10 fails
#3 (can't be helped, I think), 2.6.2 fails #1 as well (can be helped
by the above line). If run through ReSharper, both NUnits fail #2 as
well, which is related to the way evidence is passed to the test
domain: if the domain is created with evidence = null, #2 will fail,
but not if created with AppDomain.CurrentDomain.Evidence.
Note that tests must be run one at a time, with realods in-between to
get accurate results.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nunitv2/+bug/1167805/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~nunit-core
Post to : nunit-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nunit-core
More help : https://help.launchpad.net/ListHelp
