Has anyone else noticed that ODAC Release 4 & 5 have the same AssemblyVersion 18.104.22.168?
It took me a while to spot the problem. I'm using Entity Framework 5 and hit a machine with Release 4. It threw an completely misleading exception on load.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleConnectionStringBuilder' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.RegAndConfigRdr' threw an exception. ---> System.Configuration.ConfigurationErrorsException: MySchema.MyPackage.MyProcedure.RefCursorMetaData.CUROUT.Column.1 is invalid
at Oracle.DataAccess.Client.RegAndConfigRdr.AddMetadataForRefCursor(String refCursorKey, String metadataInfo, Hashtable& schemaTable)
at Oracle.DataAccess.Client.RegAndConfigRdr.RetrieveInfoFromConfig(NameValueCollection nvc, Hashtable& schemaTable, Boolean bIsCallFromODT)
Since ODAC Release 4 was installed, the machine had Oracle.DataAccess.dll (22.214.171.124) in GAC. Thus, my application could not use my local copy of Oracle.DataAccess.dll (126.96.36.199) from Release 5.
Having the same AssemblyVersion for Release 4 and 5 causes issues. Can we get an additional release with an updated version?
Thanks for the tip Alex. I can see when both are on a machine that putting Release 5 in the GAC would be the best choice.
My issue stems from hitting a machine with Release 4 only and having the GAC Assembly used instead of my local (Release 5).
Going forward with new releases can we expect the AssemblyVersion and/or FileVersion to increment always when the dll changes? I'd like to avoid the GAC work around.
To avoid the problem, I've upgraded to 12c Release 1.
Please consider updating the AssemblyVersion as well. Updating the AssemblyInformationalVersionAttribute will not help when working with local versions that have the same AssemblyVersion in the GAC as the GAC will always be used.
Ideally, we'd be able to update all our target machines for an application to the latest ODAC, but it's simply not the case.
Can you elaborate on the versioning policy for ODAC? What I'm looking for ideally is an incrementing AssemblyVersion with releases as was done previously with Oracle 11 R3, R4, R5. For example,
ODAC 12c Release 1
AssemblyVersion = 188.8.131.52
AssemblyInformationalVersionAttribute = 184.108.40.206 12c R1
ODAC 12c Release 2
AssemblyVersion = 220.127.116.11
AssemblyInformationalVersionAttribute = 18.104.22.168 12c R2
In your post https://forums.oracle.com/message/11264632#11264632 you describe best practice.
The best practice is to install 64-bit ODP.NET following the install instructions. To make sure each application can find its correct unamanged Oracle Client DLLs, I recommend setting the DllPath setting described in Chapter 2 of the ODP.NET Dev Guide. Typically, the problem people run into with multiple ODP.NET versions on the same machine is ensuring each ODP.NET version uses its correct Oracle Client version (i.e. avoiding DLL Hell). Setting DllPath is a straightforward to ensure all your ODP.NET apps will use the right dependent Oracle Client DLLs.
If we are to follow your recommend best practice then we must have different AssemblyVersions with each release. Otherwise, we could load the wrong ODP.NET Oracle.DataAccess.dll from the GAC that doesn't match the unmanaged Oracle Client dlls we specified with the DllPath setting.
If I've missed something, please let me know.
There are two issues in your last post:
1) Oracle.DataAccess.dll versioning
2) Unmanaged Oracle Client DLL referenced by Oracle.DataAccess.dll
The forum post you quote is referencing solving problem #2.
For problem #1, the ODP.NET team's preferred solution is to version every unique Oracle.DataAccess.dll release. We cannot due to a conflict with Oracle's general patching policy. Using AssemblyInformationalVersionAttribute is the best compromise.
If you've ever downloaded an Oracle patch, you will notice the files share the same version number as other patches within an Oracle patchset family. With every new patchset or major version, Oracle.DataAccess,dll can then increase its version, just like every other Oracle DLL.