If your scenarios include running an assembly in 64 bit, and there are dependencies on native components, i.e. oracle drivers, COM components, make sure that you're running each one in the same processor architecture. There are the following limitations on 64 bit Windows:
- Process cannon run 32 dlls in 64 bit address space.
- 32 bit COM components cannot be instantiated in using 64 bit assembly.
You can change assembly's build setting settings to x86 if you need to load 32 bit components. Lets go to a few examples. Microsoft Visual Studio is 32 bit application capable of building 64 bit assemblies. If you need to debug 32 bit COM component, you need to build your assembly into x86 architecture. Another example is TestDriven.NET. Latest version, 2.23, by default, matches VS architecture, i.e. x86. If you want to debug Oracle driver, you need 32 bit. You can switch TestDriven.NET to 64 bit to have architecture parity. To run tests in NUnit, I'd recommend to go everywhere with 64 bit, since there is a NUnit 64 bit, and you will be sure that there are no issues once the code is built into the product.