Suche

über alle News und Events

 

Alle News

 

Durable Function ist eine Erweiterung der...

Weiterlesen

Wir haben eine gute, vor allem spannende und hoch...

Weiterlesen

Am 09.05.2022 wurde ein Artikel von Microsoft...

Weiterlesen

Neben den altbekannten Logic Apps (Consumption),...

Weiterlesen

Im Jahr 2022 fallen eine Reihe von .Net Versionen...

Weiterlesen

SAP in die Power Platform integrieren – In einem...

Weiterlesen

Bicep Templates benutzen eine deklarative Syntax...

Weiterlesen

In BizTalk gibt es einige Alternativen, wie...

Weiterlesen

Wir sind auf ein seltsames Phänomen bei einem...

Weiterlesen

Nach der Migration konnten in VS 2019 „normale“...

Weiterlesen

How-to: Benutzung des WCFOracle Adapters unter BizTalk2020

Benutzung des WCFOracle Adapters unter BizTalk2020 oder 'Could not load file or assembly 'Oracle.DataAccess, … or one of its dependencies.'

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:

https://blog.sandro-pereira.com/2017/10/05/biztalk-server-2016-could-not-load-file-or-assembly-oracle-dataaccess-version-or-one-of-its-dependencies/ gefunden:

· 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

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz