29

I am starting to write a unit test (MS Test, with Resharper as the test runner). When I set the LogicalThreadContext (see below), my test cases get 'aborted'. Anybody know why? Is this related to the unit test being on a different thread? How do I resolve this?

[TestClass]
public class ContextInfoTest
{
    private ILog _log;


    [TestInitialize]
    public void TestInitialize()
    {
        // logging configured in assembly.info
        _log = LogManager.GetLogger(this.GetType()); 
    }


    [TestMethod]
    public void FigureOutWhyAborting()
    {
        string input = "blah";
        LogicalThreadContext.Properties["mypropertyname"] = input;

        string output = LogicalThreadContext.Properties["mypropertyname"] as string;
        Assert.AreEqual(input, output);
    }


    [TestMethod]
    public void ThisWorks()
    {
        string input = "blah";
        CallContext.LogicalSetData("mypropertyname", input);

        string output = CallContext.LogicalGetData("mypropertyname") as string;
        Assert.AreEqual(input, output);
    }

The weird thing is that if I were to debug and step through the code, the Assert.AreEqual does get called and passes, so something is happening after that line of code... which is why I think it might have something to do with the test thread, etc.

Thanks!

UPDATE: So I ran this test in MSTest and got this exception (Resharper didn't show it)

Unit Test Adapter threw exception: Type is not resolved for member 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.13.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'..

I'm using log4net v1.2.13, on VS2013, .Net 4.5.

This link seems to suggest it is a referenced assemblies problem, but there is no resolution. Any additional ideas would be greatly welcome, GAC'ing log4net is not an option. https://issues.apache.org/jira/browse/LOG4NET-398

JackPoint
  • 4,031
  • 1
  • 30
  • 42
Raymond
  • 3,382
  • 5
  • 43
  • 67
  • 1
    works fine for me (both running and debugging the test) but I'm not using reSharper. Maybe try running them directly from VS not through ReShaper – ManyRootsofAllEvil May 14 '14 at 17:58

4 Answers4

36

I ended up doing this to get it working:

put this in the TestCleanup() method:

CallContext.FreeNamedDataSlot("log4net.Util.LogicalThreadContextProperties");
Raymond
  • 3,382
  • 5
  • 43
  • 67
  • 1
    this somehow works, but not always. For some reason, that I don't know, a few tests still throws the error. – JobaDiniz Dec 06 '16 at 17:08
  • Somewhere deep in my code I found that we used the log4net LogicalThreadContext to set a property, apparently this one line caused the issue. Freeing the named data slot works for me, although I'm investigating whether we can remove that line altogether. If we have these issues in testing, I wonder if it would give side effects in production. – Erik Nov 03 '17 at 13:32
  • @Erik And Raymond : This did not work for me. I am using log4net.LogicalThreadContext.Properties[param.Key] = param.Value; But this keeps failing with the error in your original post. I now tried log4net.GlobalContext.Properties[param.Key] = param.Value; And it seems to be working. Any idea? – Milind Thakkar May 04 '18 at 10:01
1

So, I can't thank you enough for figuring this out to call FreeNamedDataSlot. This turned me on to my answer that worked for me. Instead of passing in the full namespace of the class, I just had to use the class name:

This was used somewhere deep in my Data Access Layer:

MySession session  = (MySession)System.Runtime.Remoting.Messaging.CallContext.LogicalGetData("MySession");

[TestCleanup]
public void Cleanup()
{
    CallContext.FreeNamedDataSlot("MySession");
}

This worked perfect for me! Hopefully this helps someone else when using Visual Studio's Test environment.

Ben Humphrey
  • 588
  • 5
  • 17
0

I know this is a bit old but for the following worked for me.

Although log4net was referenced by my project and my unit tests, it was not configured in the unit test. Updating my ThreadContext helper to the following allowed my tests to succeed. If log4net is configured in your unit tests and you are still getting this issue you could key off a compilation symbol instead.

var is_configured = log4net.LogManager.GetRepository().Configured;
var props = is_configured
            ? (ContextPropertiesBase)LogicalThreadContext.Properties
            : (ContextPropertiesBase)ThreadContext.Properties;
props[key] = value;
Steve
  • 1,995
  • 2
  • 16
  • 25
-2

Thanks all for the tips, i try with:

[TestCleanup]
public void Cleanup()
{
   CallContext.FreeNamedDataSlot("log4net.Util.LogicalThreadContextProperties");
}

And works!!

devcfgc
  • 89
  • 1
  • 4