Our organization, like many other medium-to-large companies, uses a central ORACLE database for most of our company-specific data. By itself this is not an issue (according to management), but problems arise from two things:
- We are almost exclusively a Microsoft shop.
- The version of ORACLE we are using is very old (8+ years).
Our need to interface with ORACLE is what drove me and my team to develop a mapping system that allowed us to map ASP.NET DataTables to strongly-typed objects. Now, however, we're running into a different set of problems.
Like most other shops (I believe), our servers run a 64-bit architecture. What I didn't realize until I started working with ORACLE about a year ago is that ORACLE actually cares about the architecture of the machine it is running on; the x86 version of ORACLE's DLL will not run on an x64 machine and vice versa.
This is problem because Visual Studio is a 32-bit application. When you start debugging a web site or application in VS, it spins up a 32-bit instance of IIS Express to host the process in. But ORACLE's 64-bit DLL won't run in this environment, so running and debugging on our local machines was something of an annoyance.
Before Visual Studio 2013 there was no easy way to run an app as a 64-bit process, so what we were doing was running locally using the 32-bit ORACLE DLL and then at deployment replacing that DLL with the 64-bit equivalent. These extra steps, though, were often loss in the shuffle of deploying an app, so it was quite a relief to us when VS 2013 was able to spin up the 64-bit version of IIS Express so that we could not have to bother with switching the ORACLE DLLs around.
In VS 2013, here's how you enable targeting a 64-bit version of IIS Express. First, go to Tools -> Options, then in the resulting window expand Projects and Solutions to find Web Projects. Click on Web Projects to open this dialog:
See that check box? If that is checked, running projects locally will cause Visual Studio to spin up a 64-bit instance of IIS Express, thereby creating a 64-bit process that the ORACLE DLL can execute within.
It's just that easy! Let me know if you found any other tricks for dealing with ORACLE in ASP.NET applications in the comments.
Happy Coding!
