I spent nearly two days trying to resolve this issue. My new desktop at work is running Windows 7 (64-bit) and some of our applications are still using System.Data.OracleClient as an adapter instead of Oracle’s own ODP.NET. Microsoft’s driver interops with Oracle’s own client installed on the developer machine (oci.dll). We need to continue running our web applications under 32-bit IIS, which is where the problem lies.
FYI… According to Microsoft:
The types in System.Data.OracleClient are deprecated. The types are supported in version 4 of the .NET Framework but will be removed in a future release. Microsoft recommends that you use a third-party Oracle provider.
Back to the comment about IIS. Apparently, IIS 7 in Windows 7 is 64-bit only. Yes, you can set an application pool to 32-bit. That would be perfectly fine, except that Oracle’s client native methods don’t like running through WoW64. So, you have to install both the 64-bit client and the 32-bit client. After all, 32-bit adapter code can’t call a 64-bit client. If you fire up procmon, though, you’ll see that calling the 32-bit Oracle client still queries 64-bit settings (and fails if they don’t exist). WoW64!, indeed.
Continue reading to see my resolution…
Note: this forces Oracle 11.2.0.1 to use 32-bit only in a 64-bit environment.
... ➦I’m a frequent Ubuntu Linux user. I don’t use Windows much, unless I’m at work. Today, I wrote a small script to parse Apache access logs and thought, “This would be a really cool utility to share with others.” Granted, it’s pretty basic and there are most likely hundreds of other utilities out there, so I’ve decided to use it as an example to installing PAR:Packer under Windows to compile perl scripts into a Windows executable.
3. Then install **PAR::Packer** for _compiling_ the Perl script. Run: ```bash
cpanm -n PAR::Packe
Continue reading for an example!
... ➦I post on Stack Overflow a lot. Sometimes, there are really interesting questions like one I answered last year. I had forgotten about it until this week when the answer was accepted. I thought I’d share it on my blog.
The original post is here. Read on for redundancy.
... ➦Here’s an interesting problem:
You have an ASP.NET Web Forms application which references jQuery 1.3.x and would require a lot of testing to upgrade to a newer version of jQuery. You’re adding functionality to this application, and you really want to use jQuery 1.5 or jQuery 1.6 going forward with new development. But…, jQuery 1.3.x is referenced in the master page. Also, you want to load jQuery UI 1.8.x targeting the newer version of jQuery.
…
... ➦