nHibernate not creating Oracle driver in MSTests run on command line - nhibernate

Question

I've been working on this particular issue for a couple weeks now, and I'm exceedingly frustrated. As such, I'll give all the information I can and hope for the best.
My team is working on building a new application. Here's the alphabet soup:
.Net 4.5.1
nHibernate 4.0.0.4000 with FluentNHibernate 2.0.3.0
Oracle 11g (Oracle.DataAccess 2.112.1.0, which has Copy Local set to true)
Visual Studio 2013 is the IDE
Windows 7 Professional
I am compiling the application as a 32-bit app, and I have confirmed that I have the 32bit version of Oracle installed.
We've written some tests for the NHibernate mappings, which we run through MSTest. When we run these through Visual Studio's test explorer, they all run properly and pass. The application itself also properly compiles and deploys as it should. We've verified the tests are running properly by checking the database between steps, so we're fairly sure that the tests themselves aren't the problem.
When we run MSTest through the command line though, we receive the following error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Unable to find the requested .Net Framework Data Provider. It may not be installed..
I've tried reinstalling Oracle to no effect. I've tried checking the machine.config file for errors (as suggested in other posts here on SO) and found none.
Our Fluent configuration is as follows:
OracleDataClientConfiguration.Oracle10
.ConnectionString(connectionString)
.Driver("NHibernate.Driver.OracleDataClientDriver")
.ShowSql()
.FormatSql();
The code I'm running on the command line is the following:
(cd to the directory where the test .dll is)
>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:MyTests.dll /test:UnitTests
I feel like I'm missing something here. Any ideas?
Update: Solution Found
So here's a weird one. I followed Fran's solution below and installed the Oracle.ManagedDataAccess package and changed the NHibernate driver in our configuration above to NHibernate.Driver.OracleManagedDataClientDriver. As per our quick comment-discussion, this lead to a new error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleManagedDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Configuration.ConfigurationErrorsException: Failed to find or load the registered .Net Framework Data Provider
Fran then lead me to another SO question which encouraged me to check the Oracle configuration piece by piece. What better way to do this than create a test?
var x = new OracleConnection(connectionString);
x.Open();
Assert.IsTrue(x.State == System.Data.ConnectionState.Open);
x.Close();
Assert.IsFalse(x.State == System.Data.ConnectionState.Open);
In my quick attempt to run this test, I ran the whole collection of UnitTests with the script I'd mentioned above. Low and behold, every test passes!
Doing my due diligence, try the following
I comment out that test, clean, rebuild, and run the script again. Failures.
I return to the old Oracle driver and add that new test in. Clean, Rebuild, Run. Failures.
Add back the new Oracle driver, make sure the new test is still in. Run tests OTHER than the new test. Passes.
For some reason, the combination of the new driver and explicitly referencing it in a test seems to have resolved the issue. I'm open for any theories as to why, but I bet that qualifies as a new question.

Answer 1

I would stop using the bit specific version of the oracle drivers and move to the managed driver (https://www.nuget.org/packages/Oracle.ManagedDataAccess/). It is bit agnostic, and doesn't require you to install the Oracle client at all.

Answer 2

I actually found the solution to the problem, and it all has to do with how the Oracle.DataAccess.dll file gets loaded at runtime (Disclosure: I work with wadeb on the same project).
It seems that Oracle.DataAccess.dll was being searched for in every location on the server except the build output folder in the Jenkins workspace, and as such was pulling the DLL file from the GAC.
One of the file paths used to find the DLL file is the folder in which the "current executable" is located. In our case, the "current executable" was mstest.exe. Copying the Oracle.DataAccess.dll file to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE did the trick.
Did it work. Yes.
Was it a hack? Absolutely -- but now it works without having to upgrade to the managed Oracle drivers.
Our servers weren't using an Oracle client that worked with the managed driver, and it wasn't acceptable to have a broken continuous integration build until servers get upgraded.

Answer 3

I have got just the same error and I switched my tests to x64 and it works like a charm now: