Build/Test Issues

NCrunch behaving strangely with AppDomains

Started by Martin Evans on 5,333 views

I'm using the AppDomainToolkit to build a plugin system and I've encountered some behaviour which is making it impossible for me to test it using NCrunch. My test code looks like this:

namespace AppdomainPlayground
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine(AppDomain.CurrentDomain);

            const string location = @"A:\Path\To\Test.dll";
            string dir = Path.GetDirectoryName(location);

            var context = AppDomainContext.Create();
            context.RemoteResolver.AddProbePath(dir);
            context.LoadAssemblyWithReferences(LoadMethod.LoadFrom, location);

            var x = RemoteFunc.Invoke<int, int>(context.Domain, 1, a => a + 1);
            Console.WriteLine(x);

            Console.ReadLine();
        }
    }
}


namespace TestProject1
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
            Program.Main(null);
        }
    }
}


Test.dll is just the build result of a C# class project with Class.cs and nothing else. Obviously this program should load that assembly, calculate 1+1 in the appdomain and then print 2. If I run this as a program or use the built in visual studio test runner everything works as expected. However, if I run this from an NCrunch test I get an exception:

FileNotFoundException was unhandled by user code

Could not load file or assembly 'AppdomainPlayground, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.


This is very odd. AppdomainPlayground should never be loaded into the appdomain and Test.dll makes no reference to AppdomainPlayground (it's a totally different project with no connection between them at all).
Hi Martin -

NCrunch works by identifying static references between projects, then linking copies of these projects together at run time to build virtual environments in order to run tests. As such, the nature of what you're doing here (i.e. generating custom application domains through dynamic assembly referencing) is certain to give problems with NCrunch. There are ways you can make elements of this approach work with NCrunch, but this will involve give and take with your design.

The project atomicity constraints can tell you more about how NCrunch constrains this particular design. Specifically, you may wish to look into tests that build their own appdomains, as this problem area is similar to yours.

Generally speaking, there needs somewhere to be static references between projects that depend on each other - otherwise NCrunch won't know about the dependencies of a project, and won't be able to build an application domain to test it.


Cheers,

Remco

Post a reply

Log in to reply.