This content has been marked as final. Show 12 replies
What is the error number and message you see?
Does the error occur when trying to load Oracle.DataAccess.dll or when trying to open the connection? You said opening a connection, but if the DLL was the problem, you would probably see an error before the Open call.
When you xcopy, I assume you ran the batch file commands and didn't manually copy over the Oracle.DataAccess.dll only. Oracle.DataAccess.dll has a number of dependent DLLs that must be copied over as well. These commands should automatically GAC the DLL for you. When you say it's not working when you try to register the DLL, what error message do you see?
Hello Alex :-)
The error is the classical "object reference not set to an instance of an object".
I used process explorer when starting my program I and saw the dll Oracle.DataAccess next to my program was loaded.
I'm not sure it is the dll itself or the open() method that is causing the issue but I would say it is the open() method (I should probably create some traces out from the program, especially to know if there is an ORA error behind).
In fact I didn't do the xcopy, I took the dll that I was interested in, use it in my program and I just deployed the program and that dll on the Client machine.
I thought it was enough to just have that dll.
Do you think it is possible to use these dependent dlls next to the program instead of deploying them into the GAC ?
About the register of the dll in the gac, I used the exe that is next to the Oracle.DataAccess.dll in the folder ... net\4\bin. The utility was telling me the dll was registered. But know I'm not sure I was looking in the right GAC... :s
ODP.NET consists of more than Oracle.DataAccess.dll. You'll have to copy the dependent DLLs as well. It's certainly possible to do that with the GUI install version, but I wouldn't recommend it because the Xcopy version is intended to fulfill that niche. Developers that create their own customized installs with the smallest install size possible should use xcopy now. This should improve even more once the fully managed ODP.NET is released.
With respect to the object reference error, it can point to many different possible solutions. It's possible that the connection object is null or getting disposed by the time you call Open(). You may want to post a code snippet of everything run up to that call.
Finally I did some tests with the xcopy.
I used the install.bat first for .net 4 without the dependencies (instantclient). My program was not working.
Then I install it with its dependencies and the program works fine.
I watch with process explorer the loaded dlls and I could identify 3 of them :
oraociei11.dll (127 mb !)
Then I uninstall everything and I copied the 3 dlls next to my program, so in total I have 4 dlls (including oracle.dataaccess.dll).
The program works perfectly!
So it is exactly what I currently need, without installing anything else I can start my program.
Thanks for the help,
I think what you meant is "unsupported". unsupported describes a scenario where an installation does not follow the steps descibed in readme / installation guide to the product - for example removing DLL's which seems to be not used etc.
Often customers want to do that - and thats the reason Oracle introduced a minimal configuration called instant clients.
This instant client is bundled with the MS API's like ODP.NET - and you can decide during install - for example when using XCOPY deployment - only to setup a minimal config - for example - Instant client + ODBC - avoiding OLEDB, ODP.NE etc.
Anyway - this is the way to get the minimal supported configuration - everything else is unsupported and a bug can only be logged if the issue is reproducable in a correctly configured environment.
But even the Instant Client is to large for some customers so Oracle developed a Managed Provider which consist only of ONE DLL - size ~ 6 MB. In opposite to the unmanaged Provider it does not use the OCI DLLs which call the Oracle Network funtions from big ~ 100MB oraociei11.dll - it implements all the stuff itself using C#.
Comparing managed provider with unmanaged provider is like JDBC/Thin with JDBC/OCI.
If you want to give the Beta Managed Provider 184.108.40.206.50 a chance - look here:
next patch 220.127.116.11 and upcoming 12.1 will ship managed provider as ready-to-use product and when using "alias-less" connection you dont even need a tnsnames.ora or sqlnet.ora.
I hope one file 6MB is less enough ;-)
Edited by: fscherie on 07.11.2012 15:51
imterpsfan2 wrote:Personally... it depends. We have one application in my shop using it right now in production because the alternative was a total logistical nightmare. We did a boatload of testing on it and in that specific application, beta or not it worked perfectly for what we need. Nothing else has used it outside of experimental purposes though, and we're holding off on other applications.
Isn't that still in BETA?
Would you trust that in a production environment?
Normally it's not a great idea, but sometimes it's still better than the alternatives. It depends on the situation, the users, how easy it is to push updates out, etc.