Moles hosting unable to resolve dependent assembly

Question

I'm developing a test method where both RhinoMocks as well as Moles are used. I have declared the host type as Moles for the test method as required. Now when it comes to the point where RhinoMocks has to emit a runtime assembly to create a mock for an interface, a FileNotFoundException is thrown, pointing to one of my private DLLs, which infact resides in the same folder as the test DLL and the DLL containing the class under test.

But when I remove the HostType attribute, the creation of mock instance works just fine, without any exceptions.

So, I built a workaround to get this to work with the Moles host type using these following steps:

1) I registered to the AppDomain.CurrentDomain.AssemblyResolve event in my [TestInitialize]

2) In the event handler, I packed in the following logic:

System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        string asmPath = Environment.CurrentDirectory + "\\" + args.Name.Split(',')[0] + ".dll";
        if(System.IO.File.Exists(asmPath))
            return System.Reflection.Assembly.Load(new System.Reflection.AssemblyName(args.Name));
        return null;
    }

Now, as expected, this assembly resolver does get invoked when the test is executed under the Moles HostType. The test now runs.

But the questions still are:

1) why do I still need a separate assembly resolver even if we explicitly set the AppDomain's APPBASE path to the folder containing all my production DLLs and the test DLL using

AppDomain.CurrentDomain.SetData("APPBASE", Environment.CurrentDirectory);

where I've checked that the current directory is indeed my bin folder where every binary, including the test DLL, can be found.

2) Why do I not encounter this error when I'm testing some other production DLL of mine, where the same dependencies are involved.

3) This problem occurs also when using NMock2, which I tried just to see if this was a RhinoMocks-specific problem. But turns out that even NMocks2 has the same problem in the Reflection.Emit step, with the same dependent DLL as with RhinoMocks. Any way to explain this?

Answer 1

The part you are missing is that when you run the unit test the app which is running is the unit test hosts the application. The CurrentDirectory of that application is probably the directory in which its runner is installed. Your assemblies are passed in with parameters to the application.

The assumption that the CurrentDirectory is the directory of your application is faulty, this explains points 1, 2 and 3.