Any solutions for using Moq and NHibernate together in .NET 4.0?

Using NHibernate 3.1 and Moq 4.0.10827 in my unit tests, all this running in .NET 4.0, I get the following error if the tests all run one after another in the same domain:

NHibernate.HibernateException : Creating a proxy instance failed ----> System.InvalidCastException : Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.Runtime.Hosting.IClrStrongName'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{9FD93CCF-3280-4391-B3A9-96E1CDE77C8D}' failed due to the following error: Interface not registered (Exception from HRESULT: 0x80040155).

This error does not fail when I run tests that use Moq separately from those that don't.

Interestingly enough, when I still had the .NET 3.0 version of Moq, I was getting a similar cast COM object... error when I ran a series of Moq tests. I since switched to the 4.0 version of Moq.

I some information concerning this error (look near the bottom, in Troubleshooting): http://blogs.msdn.com/b/clrteam/archive/2010/06/23/in-proc-sxs-and-migration-quick-start.aspx

Specifically, it says:

If your application instantiates and uses COM components through the .NET Runtime’s managed interop layer, and one of those COM components happens to be managed, then there is a small chance that after migrating your application you might run into an error similar to [error above].

This error can occur as a result of the following two combined conditions:

1. The managed COM component is registered against a different .NET Runtime version from that of the instantiating caller, causing it to be activated in another runtime than that of the instantiating caller.

2. The interface is not marked with System.Runtime.InteropServices.ComVisibleAttribute, with a value of true.

This scenario worked in the past because of a runtime optimization: when the .NET Runtime notices that a COM type it instantiates has a managed implementation, and that it was instantiated into the same Application Domain as the instantiating caller, it bypasses the managed interop layer and returns to the caller the managed object itself. In prior .NET Framework releases (where in-proc SxS was not available), all managed COM types and their managed clients were commonly loaded into the same Application Domain, allowing the implementing managed object to be returned, and in turn allowing the interface cast succeed without being marked as ComVisible.

Migrating an application can easily create condition 1; if the application also relies on condition 2 (which is much less common), then the above error will be encountered. There are a couple of solutions available:

1. Get an updated version of the managed COM type that properly declares the interface as ComVisible.

2. Update the application configuration file to use the useLegacyV2RuntimeActivationPolicy extension.

It seems that they may be something in .NET 4 that the Castle DynamicProxy doesn't like? I did find a message on the Castle mailing list, which hints at that.

I did try using the useLegacyV2RuntimeActivationPolicy="true" switch in the unit test assembly's app.config (ReSharper 6). I also tried the same switch in the native NUnit runner.

Any ideas?