nunit-core team mailing list archive

[Launchpad Bug Tracker <1167805@xxxxxxxxxxxxxxxxxx>]

** 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