After a lot of deployment issues with full client, we thought we had the solution with Instant Client.
It worked great for a while, but now some of our users have full Oracle 11 client installed after installing our Instant Client because of other software that requires full client.
As soon as they install full client, our Instant Client breaks: Exception has been thrown by the target of an invocation. (mscorlib) The type initializer for 'Oracle.DataAccess.Client.OracleClientFactory' threw an exception. The provider is not compatible with the version of Oracle client (Oracle Data Provider for .NET)
Our instant client is compiled with 220.127.116.11, the client is installing a different version (though I tried installing exactly same version does not seem to work either)
I've been experimenting to redirect the version to another assembly but no success.
How can I make Instant Client and Full client co-exist? The whole idea of using Instant was to be independent of other software who needs ODP.NET...
What do you do when 2 apps need different versions of ORacle ODP.NET (e.g. 18.104.22.168 vs. 22.214.171.124)?
Note that I don't have source code access to "our" app, so if it is at all possible through configuration, that is a prefered solution.
I also don't control our customers deployment strategy, they roll out apps over 1000's of PC's
Having two oracle clients co-exists is tricky on windows, though its fairly convenient on Unix/Linux.
You have to go through what all registry variables the install scripts are going to set.
You had a working Instant Client but after a full Install its gone messy as the full install would have set few registry variables pointing to the full client installation
Even a simple environment variable like PATH and which install's bin is being picked up by the app and if that indeed the right version to pick or not can mess up our lives. If you can set and control all these variables for each of your installations through scripts and remove them from registry then you can have multiple oracle clients on the same box.
According to documentation at [http://docs.oracle.com/cd/E20434_01/doc/win.112/e23174/featConfig.htm]
> Configuration File Support
For customers who have numerous applications on a computer that depends on a single version of ODP.NET, the Windows Registry settings for a given version of ODP.NET may not necessarily be applicable for all applications that use that version of ODP.NET. To provide more granular control, ODP.NET Configuration File Support allows developers to specify ODP.NET configuration settings in an application config, web.config, or a machine.config file.
If a computer does not require granular control beyond configuration settings at the ODP.NET version level, there is no need to specify ODP.NET configuration settings through configuration files.
The following is an example of a web.config file for .NET Framework 2.0 and higher:
<?xml version="1.0" encoding="utf-8" ?>
<add name="DllPath" value="C:\oracle\bin"/>
<add name="FetchSize" value="131072"/>
<add name="PromotableTransaction" value="promotable"/>
<add name="StatementCacheSize" value="10"/>
<add name="TraceFileName" value="C:\odpnet2.trc"/>
<add name="TraceLevel" value="63"/>
<add name="TraceOption" value="1"/>