Unfortunately, I\'m trying to use Oracle from .NET and it\'s like going to back to 1997. Explaining things properly is a sign of weakness and the registry and environment variab
First off, +1 for your unadulterated love of Oracle, and realizing that they are the best company with the best products! ;)
Yeah the download and install process is ridiculous. I usually can't even find the right client download on their site, and the Oracle Universal Product Installer thing is terrible.
Sometimes you will need a copy of OraOps11w.dll
in your \bin
directory. Sometimes not. I've never figured out when its needed and when it isn't, but I think that if your referenced Oracle.DataAccess.dll
isn't exactly the same version as the installed Oracle client, then you need the OraOps11w.dll
.
Can you explain what you are trying to do in your config file with DllPath
? The Oracle install should have registered just about everything it needs in the machine.config
for your .NET Runtime. It has been a while since I set up ODP.NET, but I don't remember there being much to put in the app.config, other than the connection string.
I've spent days in the past trying to get Oracle connected in Windows 7.
The problem I encountered was that I had a 32-bit ASP.NET application with the 32-bit Oracle ODP.NET drivers installed. I wasn't aware that, even though the ASP.NET application runs as a 32-bit process and requires the 32-bit ODP.NET, IIS is a 64-bit process and causes ODP.NET to access the 64-bit registry keys. You didn't mention whether you were trying to setup Oracle for ASP.NET, but I'll share my fix (although it is for the Oracle 10.2 install).
(I'm copying this verbatim from my blog post)
Note: this forces Oracle 11.2.0.1 to use 32-bit only in a 64-bit environment.
The first mistake I made was to install the Oracle 10g client on Windows 7. This WILL NOT work. If you install it, you will have to perform some cleanup afterward.
HKLM\SOFTWARE\Wow6432Node\ORACLE\inst_loc
points to the proper location (probably C:\oracle\Inventory)HKLM\SOFTWARE\Wow6432Node\ORACLE\VOBHOME2.0
to the 32-bit Oracle folderORACLE_HOME
environment variable and point it to the 32-bit folder.Now you should be all set after a restart.
If you tried installing the Oracle 10g client, you'll have to perform some cleanup. First, make sure Oracle 10g is completely uninstalled, dereferenced from your PATH variable, and the directory is removed. Then, find the assemblies referenced in the GAC:
gacutil /l | find /i "Oracle" > c:\[some directory]\oracle.txt
Find the lines referring to Oracle.DataAccess version 10.2 and remove them from the GAC. As an example (this won't work unless you have the same version installed):
gacutil /u "Oracle.DataAccess, Version=10.2.0.100, Culture=neutral, PublicKeyToken=89b483f429c47342"
When I did this, I had three assemblies to remove:
Again, you'll probably need to restart (hey, it's Windows).
If you need to perform any cleanup, I've also blogged about that
For reference
In case the link to the "Dummy registry entry" steps dies, here's the text from that post by Gadi:
"" Hi Ben,
At design time, when working with the SQL Server Business Intelligence Development Studio, the Oracle Connector is running in 32-bit mode and therefore it loads the 32-bit Oracle client.
Most likelly, you are getting the error because the connector is loading the wrong Oracle client (oci.dll), where the TNS service is not defined.
To solve the problem, you have two options:
Specify the Oracle connection string, instead of the TNS service name in the Oracle Connection Manager Editor, for example, in the following format: host:port/service_name
Define a dummy registry entry (Z_SSIS
) as follows:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE
.Z_SSIS
(to make sure it's the last entry).Z_SSIS
node and click on New -> String.ORACLE_HOME
.ORACLE_HOME
and set it to the location of the Oracle 32Bit installation home directory you whant to use.Regards,
Gadi ""
I don't believe this is a path issue. "An attempt was made to load a program with an incorrect format." is an error that almost always means that you are mixing 32-bit and 64-bit assemblies and DLLs in .NET.
I noticed you installed the 64-bit Oracle client, I am assuming since the DSN creation worked that you are on a 64-bit version of the OS? Your problem could be from a number of related scenarios:
I believe if your app targets x86 specifically, you must install the 32-bit Oracle client package regardless of the underlying OS platform (e.g. you still would need the 32-bit Oracle client for a 32-bit app even if you were using a 64-bit version of Windows)
a couple of things to check:
Lastly, have you tried to built-in .NET data provider for Oracle (System.Data.OracleClient namespace?)
That's the best I can do since I don't know more about your projects settings for your app.
The simplest way to explain the issue is to point out the difference between the Oracle Client and the ODAC client libraries.
On a 64-bit machine (Windows 7+), you need to have installed the 64-bit Oracle Client. This is the client your machine will use to connect to Oracle databases that are deployed locally on your machine. For apps hosted on a web server or other terminal server, the rule is the same.
The trick is this... as a developer, our machines must also have the .Net IDE tooling. Oracle has a crappy naming convention but essentially there are 2 pieces: ODT (tooling) and ODAC (data access). The ODP.Net data provider is a part of the ODAC libraries.
So... back to the IDE... Visual Studio is 32-bit and therefore we must install the tooling above in 32-bit.
While developing, debugging, etc. VS.Net is using the 32-bit client libraries and data access libraries to work with Oracle.
As soon as you deploy this application to a machine, it uses whatever Client is loaded on the machine unless a specific platform is targeted.
This means if you target 32 and deploy to 64, it will break... and vice versa. The best thing to do is leave it on the any platform section, and simply remember what the hell you are doing :)
The other thing to be careful with is to ensure both your Client and ODAC packages are of the same version... you do not want to have 11g R2 client, and 11g R5 ODAC, because as soon as you deploy, crap breaks again.
The caveat here is if you wish to "embed" the oracle client inside your application, in which case OraOps alongside several other libraries are deployed with the application - this is called Oracle's Instant Client, and is also a part of the ODAC package and included in their full blown Client package as well.
Oracle is soon (2013 Q1) to release their next ODP.Net package... which will be a fully managed-code library... meaning no more separate client or ODAC package to match up, and the platform will be ignorant of 32 and 64 bit distinctions... it will function much like the old microsoft library will, only it will be built and maintained by oracle with a more robust feature set. I only wish it would arrive sooner.
I have had the same problem and found that running the unconfigure and configure bat files in the copy version of the Oracle.DataAccess.dll 11.x software install may solve or help solve the problem.
E.G. configure.bat xxx.netx xxx\product\11.2.0\client_1