I can't say I know a lot about Oracle, but I do know it's a pain in the arse to get it working without having to install massive amounts of fluff that you don't need. I really don't like builds that have "installation" dependencies. They always trip you up when setting up a new machine, and can be tricky to understand. I like my build dependencies (including binaries) in my repository so that I can check out the source and build without much effort.

It took about 3 full days (pairing with this guy) to finally figure out a solution. Many yaks were shaved, and we still don't have enough hair to stuff a pillow. The solution isn't the best; in fact it's introduced a new problem as you will soon see, but it's a compromise we are willing to make in the time being.

The context of the problem is as follows:

As a developer, I want to be able to run my integration test project against a setup Oracle database without having to install 600MB of Oracle client tools.

We've managed to break the problem down into 3 steps:

1. What Libs do I need?

This really stretched our Google-fu. I barely found the forum post that provide us the best help in solving this. A big thanks goes to the guys in this post, because with this 1 single page I don't think we would have figured this out.

• Oracle.DataAccess.dll (Grab from a full client install)
• OraOps11w.dll (ditto)
• orannzsbb11.dll (Grab from instant client basic package)
• oraociei11.dll (ditto)
• oci.dll (ditto)

We used the 11.2.0.1.0 version for all the binaries and put them in the /Dependencies/Oracle folder of our application source.

2. Put those Libs where they belong

Those binaries aren't doing us any good sitting in that folder. When we run our tests that hit the database, they need to be with all the artifacts of the test project so we add them to the .csproj like so:

<ItemGroup>
    <Content Include="..\Dependencies\Oracle\*.dll">
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
</ItemGroup>

3. Dealing with the NUnit console runner

Normally our build task to run NUnit would launch NUnit from \Dependencies\NUnit but we could not get that to recognize the Oracle dll's unless nunit-console.exe and the Oracle libraries were in the same folder. So instead of launching nunit-console.exe from the dependency folder we copy the entire NUnit folder contents to the directory where the Test project artifacts live and launch it from there.

Conclusion

Not the most elegant thing in the world, but I prefer it to installing a massive amount of files that I don't know anything about. The one major negative about this is that oraociei11.dll is over 100MB! This makes it unacceptable for a distribute team but for a team connected by a gigabit network it's tolerable.

If this helps anyone out there I would love to hear about it. Trying to solve this issue cost us a lot of time and I can only imagine how much time has been wasted globally dealing with this kind of garbage.