Die Story:
Beim Versuch über BizTalk2020 Informationen über den WCFOracle-Adapter in eine Oracle-Datenbank zu schreiben, wurde ein Fehler "Could not load file or assembly 'Oracle.DataAccess, Version=4.122.18.3, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies." geworfen.
Hier fehlt wohl der OracleTreiber "Oracle.DataAccess" auf dem Server, so der erste Gedanke.
Die Analyse der GAC-Einträge ließ allerdings nicht vermuten, dass hier etwas fehlt:
Für sowohl 32Bit als auch 64Bit waren Treiber installiert.
Erste Auffälligkeit: Die Treiber waren nur im GAC der "alten" .NET 2.x -Welt zu finden (also unter C:\Windows\assembly") nicht aber in der .Net 4.x -Welt (also c:\Windows\.NET-Framework\assembly")
Hier nun die erste Hürde: Die Oracle-Treiber der Version 2.112.x (die zur laufenden Oracle-Datenbank passen) konnten unter dem .Net-Framewerk 4.x nicht registriert werden.
Den ersten Schritt zur Lösung haben wir dann bei Sandro Pereira unter seinem Beitrag:
· Im 'neuen' GAC unter 'C:\Windows\Microsoft.NET\Framework\Vx.\Config\' können die machine.config Dateien so angepasst werden, dass das .NET-Framework durch ein "bindingRedirect" den Weg zum richtigen Treiber findet.
· An insgesamt 4 Stellen können diese Einträge gemacht werden:
o C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
o C:\Windows\Microsoft.NET\Framework\v4.0.30319\CONFIG\machine.config
o C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config
o C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
· Hier müssen dann folgenden Einträge hinzugefügt werden:
<!--<runtime />-->
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" />
<bindingRedirect oldVersion="4.122.18.3" newVersion="2.112.1.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
· Die hier eingetragenen Versionen lassen sich wie folgt festlegen:
o OldVersion: Ist die Version, die die aufrufenden Instanz erwartet. Die erfahren wir aus der Fehlermeldung
o NewVersion: Hier die Version des tatsächlich installierten Treibers (aus der GAC-Auflistung)
o Der Public KeyToken lässt sich ebenfalls aus der Fehlermeldung ablesen
Hoffnungsvoll haben wir nun einen weiteren Test durchlaufen und haben nach wie vor die selbe Fehlermeldung erhalten. Fazit: Das war noch nicht alles!
Unser Sendport im Biztalk verwendete einen 32Bit-Host. Die Umstellung auf einen 64Bit-Host brachte dann den ersten funktionierenden Zugriff auf die OracleDB. Aber warum nur 64Bit?
Weitere Nachforschungen haben uns nun auf folgenden Sachverhalt gestoßen:
Im GAC sind neben den Treiben und den dazu gehörenden Resources auch noch Policy-Dateien registriert.
Wie wir aber hier sehen, existierte bis dato nur die 64-Bit-Version der Policy. Daher die Fehlermeldung bei der Benutzung eines 32-Bit-Hosts.
Nun galt es diese Prolicy -Datei zu finden und im GAC zu registrieren.
· Die Datei konnten wir im Oracle-Installationsverzeichnis "Oracle\product\11.2.0\client_1_32Bit\ODP.NET\PublisherPolicy\2.x" finden.
· Die Registrierung in der BizTalk-Konsole (Hinzufügen einer Resource) hat aber leider nicht funktioniert. Daher die Installation über die Powershell:
## EnterpriseService-Objekt erstellen
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
## 64 Bit Version der Policy.dll
$publish.GacInstall("C:\Oracle\product\11.2.0\client_2_64Bit\odp.net\PublisherPolicy\2.x\Policy.2.111.Oracle.DataAccess.dll")
## 32 Bit Version der Policy.dll
$publish.GacInstall("C:\Oracle\product\11.2.0\client_1_32Bit\odp.net\PublisherPolicy\2.x\Policy.2.111.Oracle.DataAccess.dll")
Nun ist auch die Policy.2.111.Oracle.DataAccess für 32 Bit im GAC zu finden:
Nun waren dann die Test sowohl unter dem 32-Bit- als auch unter dem 64-Bit-Host erfolgreich :-)
Was lernen wir daraus?
Ein Redirect in den "machine.config" - Dateien auf den ODAC 2.112.1.0 reicht nicht aus, dass die entsprechenden Treiber gefunden werden. ODAC greift hier offensichtlich direkt auf die Publisher Policies, die auch im GAC registriert sein müssen. Diese Registrierung wird für die 32Bit-Version leider nicht von der Installation der Oracle-Treiber vorgenommen.
Ein quiTeq-Tipp von Thomas, QUIBIQ Stuttgart
