Ich versuche , das verwenden Oracle ODP.NET 11g (11.1.0.6.20) Instant Client auf meinem ASP.net Projekt als Daten - Provider , aber wenn ich die aspx Seite betreibe ich ein "get Der Anbieter ist nicht kompatibel mit der Version of Oracle client "Fehlermeldung. Jede Hilfe wäre dankbar.

Ich habe in Visual Studio 2005 auf den Datenprovider verwiesen, und der Code dahinter sieht folgendermaßen aus:

using Oracle.DataAccess.Client;
..

OracleConnection oOracleConn = new OracleConnection();
oOracleConn.ConnectionString =
    "Data Source=MyOracleServerName;" +
    "Integrated Security=SSPI";
oOracleConn.Open();

//Do Something

oOracleConn.Close();

Der Fehler für die Seite sieht folgendermaßen aus:

Exception Details: Oracle.DataAccess.Client.OracleException: The provider is not compatible with the version of Oracle client

Source Error: 
Line 21: 
Line 22: 
Line 23:             OracleConnection oOracleConn = new OracleConnection();
Line 24:             oOracleConn.ConnectionString =
Line 25:                 "Data Source=MyOracleServerName;" +

[OracleException (0x80004005): The provider is not compatible with the version of Oracle client]
   Oracle.DataAccess.Client.OracleInit.Initialize() +494
   Oracle.DataAccess.Client.OracleConnection..cctor() +483

Stack Trace: 
[TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception.]
   Oracle.DataAccess.Client.OracleConnection..ctor() +0
   Boeing.IVX.Web.RoyTesting.Page_Load(Object sender, EventArgs e) in C:\Documents and Settings\CE218C\Desktop\IVX.Net\Web\IVX\RoyTesting.aspx.cs:23
   System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +15
   System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +33
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1436

Ich habe mich weiter mit diesem Problem befasst, und Sie müssen einfach alle entsprechenden DLLs aus derselben heruntergeladenen Version von ODP.Net herunterladen und in denselben Ordner wie Ihre Exe-Datei legen, da ODP.Net pingelig ist, wenn es darum geht, nicht zu mischen Versionsnummern.

Ich habe hier erklärt, wie das geht: http://splinter.com.au/using-the-new-odpnet-to-access-oracle-from-c Hier ist der Kern davon:

• Laden Sie ODP.Net herunter
• Entpacken Sie die Datei
• Entpacken Sie alle darin enthaltenen JARs
• Schnapp dir diese DLLs, die gerade entpackt wurden:
  • oci.dll (umbenannt von 'oci.dll.dbl')
  • Oracle.DataAccess.dll
  • oraociicus11.dll
  • OraOps11w.dll
  • orannzsbb11.dll
  • oraocci11.dll
  • ociw32.dll (umbenannt in 'ociw32.dll.dbl')
• Legen Sie alle DLLs in demselben Ordner ab wie Ihre C # Executable

Sie sollten zunächst alle x86 / x64-Gespräche hier "ignorieren" und stattdessen den ODP.NET Managed Driver ausprobieren (wenn Sie .Net v4 + verwenden):

https://www.nuget.org/packages/Oracle.ManagedDataAccess/

https://www.nuget.org/packages/Oracle.ManagedDataAccess.EntityFramework/

Oracle ODP.net Managed vs Unmanaged Driver

Vermeiden Sie alle "nicht verwalteten" welche DLL welche Architekturprobleme! : D (ungefähr Zeit Oracle).

Das NuGet-Paket (funktioniert auch für 11g):

Die alte / manuelle Methode:

Informationen zum Konvertieren in die verwalteten Bibliotheken:

• Zunächst finden Sie hier einen hervorragenden Codevergleich zwischen verwaltet und nicht verwaltet : http://docs.oracle.com/cd/E51173_01/win.122/e17732/intro005.htm#ODPNT148
• Stellen Sie sicher, dass Sie nur die ODP.NET-Version von Managed Driver Xcopy heruntergeladen haben
• Kopieren Sie aus der heruntergeladenen Zip-Datei und fügen Sie sie in Ihr Projektverzeichnis ein:
  • Oracle.ManagedDataAccessDTC.dll
  • Oracle.ManagedDataAccess.dll
• Fügen Sie einen Verweis auf Oracle.ManagedDataAccess.dll hinzu
• Stellen Sie sicher, dass Ihre Exe mit beiden DLLs freigegeben ist ( in VS2010 zum Anwendungsordner hinzugefügt)

Ich habe nur den Oracle Data Provider für .NET 2.0 (11.1.0.6.20) installiert und den Oracle Instant Client (11.1.0.6.0) nicht installiert .

Ich habe es gerade installiert und der Fehler ist verschwunden!

Dies kann durch Ausführen einer 64-Bit-.NET-Laufzeit auf einem 32-Bit-Oracle-Client verursacht werden. Dies kann passieren, wenn auf Ihrem Server die App 64-Bit ausgeführt wird. Die .NET-App wird mit der 64-Bit-Laufzeit ausgeführt. Sie können das CPU-Flag in Ihrem Projekt in VS so setzen, dass es zur 32-Bit-Laufzeit ausgeführt wird.

Lassen Sie uns eine Art Zusammenfassung machen:

Die Fehlermeldung "Der Anbieter ist nicht mit der Version des Oracle-Clients kompatibel" kann verschiedene Gründe haben.

• Sie haben keinen Oracle Client installiert. In diesem Fall ist die Fehlermeldung tatsächlich irreführend.

  Oracle Data Provider für .NET (ODP.NET, dh Datei Oracle.DataAccess.dll) ist nicht im Oracle Instant Client enthalten, sondern muss separat installiert werden (Download von 32-Bit-Oracle-Datenzugriffskomponenten (ODAC) oder 64-Bit-Oracle-Datenzugriffskomponenten (ODAC). ODAC) Downloads ) oder Sie müssen die entsprechende Option in Oracle Universal Installer (OUI) auswählen.

  Beachten Sie, dass bei der Installation des Oracle Data Providers> = 12.1 der Provider nicht automatisch in GAC registriert wird. Sie müssen es bei Bedarf manuell registrieren, siehe Oracle Doc 2272241.1 .

• Die Version von ODP.NET stimmt nicht mit der installierten Version von Oracle Client überein. Sie müssen sogar die Nebenversionsnummer überprüfen! Beispielsweise ist Oracle.DataAccess.dllVersion 4.112.3.0 nicht mit Oracle Client 11.2.0.4 kompatibel . Überprüfen Sie die Versionen von ODP.NET und Oracle Client sorgfältig. Sie können sigcheck on oraociei*.dllund / oder verwenden OraOps*w.dll, um die Version von Oracle Client abzurufen .

  Beachten Sie unterschiedliche Nummerierungsschemata. Dateiversion 4.112.3.0 Mittel: .NET Framework Version 4, Oracle Veröffentlichung 11.2.0.3.x .

  Es gibt ODP.NET-Versionen "1.x", "2.x" und "4.x". Diese Nummern beziehen sich auf Microsoft .NET Framework-Versionen 1.0.3705 / 1.1.4322, 2.0.50727 und 4.0.30319. Die Version "1.x" war bis Oracle Client 11.1 verfügbar. Die Version "4.x" wurde mit Oracle Client 11.2 eingeführt

• Die Architektur (32 Bit oder 64 Bit) von ODP.NET stimmt nicht mit Ihrer Anwendungsarchitektur überein. Eine 32-Bit-Anwendung funktioniert nur mit 32-Bit-Oracle-Client / ODP.NET bzw. eine 64-Bit-Anwendung benötigt 64-Bit-Oracle-Client / ODP.NET. (Es sei denn, Sie verwenden den ODP.NET Managed Driver. )

• Die .NET Framework-Version stimmt nicht überein. Wenn Sie beispielsweise Ihre Anwendung mit Target .NET Framework 2.0 kompilieren, können Sie ODP.NET Version 4.x nicht verwenden. Die .NET Framework-Zielversion muss gleich oder höher als die Version von ODP.NET sein.

• Die Version Oracle.DataAccess.dllauf Ihrem Entwicklungscomputer (dh die Version, die beim Kompilieren geladen wird) ist höher als die Version auf dem Zielcomputer.

• Beachten Sie, dass dies Oracle.DataAccess.dllmöglicherweise von GAC geladen wird, das standardmäßig Vorrang vor lokal bereitgestellten Dateien hat.

Lösungen

• Erwägen Sie die Verwendung des verwalteten ODP.NET-Treibers. Dieser kann von der Oracle-Seite heruntergeladen werden: 64-Bit-ODAC-Downloads (Oracle Data Access Components) . Dort müssen Sie nur die Oracle.ManagedDataAccess.dllDatei in Ihr Anwendungsverzeichnis kopieren , sonst ist nichts erforderlich. Es funktioniert sowohl für 32bit als auch für 64bit.

• In Ihrem *.csproj, resp. *.vbprojBearbeiten Sie Ihren Verweis auf ODP.NET folgendermaßen:

  <Reference Include="Oracle.DataAccess">
    <SpecificVersion>False</SpecificVersion>
    <Private>False</Private>
  </Reference>

  Attribute wie Version=...oder processorArchitecture=...sind nicht erforderlich. Ihre Anwendung wird Oracle.DataAccess.dllabhängig von der ausgewählten Architektur und dem Ziel-.NET-Framework (sofern es ordnungsgemäß installiert ist) korrekt geladen -> nicht zu 100% überprüft

• Falls Sie die Version von Oracle Client auf dem Zielcomputer nicht kennen (z. B. möglicherweise der Computer Ihres Kunden): Gehen Sie zur oben genannten Download-Seite und laden Sie die niedrigste XCopy- Version von Oracle Data Access Components herunter . Extrahieren Sie die Zip- Oracle.DataAccess.dllDatei und kopieren Sie nur die Datei auf Ihren lokalen Computer. Verweisen Sie in Ihrem VS-Projekt auf diese (höchstwahrscheinlich veraltete) DLL. Die Version dieser DLL ist die niedrigste Version von ODP.NET, mit der Ihre Anwendung arbeiten wird. Wenn Sie Ihre Anwendung ausführen, leitet die Publisher-Richtlinie in GAC zur tatsächlich installierten Version um.

• Ich denke nicht, dass es ein kluger Ansatz ist, einzelne DLLs in bestimmte Ordner zu kopieren. Es funktioniert möglicherweise auf einem "nackten" Computer, aber wenn Ihr Zielcomputer Oracle-Produkte installiert hat, besteht ein hohes Risiko für Versionsinkongruenzen. Deinstallieren Sie alle Oracle-Produkte von Ihrem Computer und führen Sie eine Neuinstallation durch. Schauen Sie sich an, wie Sie Oracle 11g (Client) deinstallieren / vollständig entfernen. es geht darum, eine wirklich saubere Maschine zu bekommen.

• Wenn Sie gleichzeitig mit 32-Bit- und 64-Bit-Anwendungen arbeiten müssen, befolgen Sie diese Anweisungen, um beide Versionen auf einem Computer zu installieren:

Annahmen: Oracle Home heißt OraClient11g_home1, Client-Version ist 11gR2.

• Entfernen Sie optional alle installierten Oracle-Clients

• Laden Sie beispielsweise Oracle x86 Client herunter und installieren Sie es in C:\Oracle\11.2\Client_x86

• Laden Sie den Oracle x64-Client herunter und installieren Sie ihn in einem anderen Ordner, z C:\Oracle\11.2\Client_x64

• Öffnen Sie das Befehlszeilentool, wechseln Sie normalerweise zum Ordner% WINDIR% \ System32 C:\Windows\System32und erstellen Sie einen symbolischen Link ora112zum Ordner C:\Oracle\11.2\Client_x64(siehe unten).

• Wechseln Sie normalerweise in den Ordner% WINDIR% \ SysWOW64 C:\Windows\SysWOW64und erstellen Sie einen symbolischen Link ora112zum Ordner C:\Oracle\11.2\Client_x86(siehe unten).

• Ändern Sie die PATHUmgebungsvariable, ersetzen Sie alle Einträge wie C:\Oracle\11.2\Client_x86und C:\Oracle\11.2\Client_x64durch C:\Windows\System32\ora112ihren jeweiligen \binUnterordner. Hinweis: C:\Windows\SysWOW64\ora112darf sich nicht in der PATH-Umgebung befinden.

• Setzen Sie bei Bedarf Ihre ORACLE_HOMEUmgebungsvariable aufC:\Windows\System32\ora112

• Öffnen Sie Ihren Registrierungseditor. Setzen Sie den Registrierungswert HKLM\Software\ORACLE\KEY_OraClient11g_home1\ORACLE_HOMEaufC:\Windows\System32\ora112

• Setzen Sie den Registrierungswert HKLM\Software\Wow6432Node\ORACLE\KEY_OraClient11g_home1\ORACLE_HOMEauf C:\Windows\System32\ora112(nicht C:\Windows\SysWOW64\ora112)

• Du bist fertig! Jetzt können Sie den x86- und den x64-Oracle-Client nahtlos zusammen verwenden, dh eine x86-Anwendung lädt die x86-Bibliotheken, eine x64-Anwendung lädt die x64-Bibliotheken ohne weitere Änderungen auf Ihrem System.

Befehle zum Erstellen symbolischer Links:

cd C:\Windows\System32
mklink /d ora112 C:\Oracle\11.2\Client_x64
cd C:\Windows\SysWOW64
mklink /d ora112 C:\Oracle\11.2\Client_x86

Einige Notizen:

• Beide symbolischen Links müssen denselben Namen haben, z ora112.

• Wenn Sie ODP.NET anschließend manuell installieren möchten, müssen Sie die entsprechenden Ordner für die Installation auswählen.

• Trotz ihrer Namen C:\Windows\System32enthält der Ordner die x64-Bibliotheken, während er C:\Windows\SysWOW64die x86-Bibliotheken (32-Bit) enthält. Sei nicht verwirrt.

• Vielleicht ist es eine kluge Option, Ihre TNS_ADMINUmgebungsvariable (bzw. TNS_ADMINEinträge in der Registrierung) auf einen gemeinsamen Speicherort zu setzen TNS_ADMIN=C:\Oracle\Common\network.

Nach mehreren Stunden der Fehlerbehebung stellte ich fest, dass dieses Problem durch Oracle.DataAccess.dll (v4.0) in meinem Projekt-Bin-Verzeichnis verursacht wurde, die Laufzeit jedoch auch Oracle.DataAccess.dll (v2.x) aus dem GAC lud. Das Entfernen und Lesen des Oracle.DataAccess-Eintrags in den Projektreferenzen löste das Problem für mich.

Die anderen hier genannten Dateien schienen in meiner Situation nicht notwendig zu sein.

AKTUALISIEREN

Die Hauptursache für den Fehler "Der Anbieter ist nicht mit der Version des Oracle-Clients kompatibel" ist (im Allgemeinen), dass die verwaltete Assembly versucht, nicht verwaltete Bibliotheken zu laden, die nicht mit den Versionen übereinstimmen. Anscheinend können Sie den Oracle-Treiber zwingen, die richtigen Bibliotheken zu verwenden, indem Sie den Bibliothekspfad in der Datei web.config ¹ angeben

<configuration>
  <oracle.dataaccess.client>
    <settings>
      <add name="DllPath" value="C:\oracle\bin"/>
      <!-- ... -->
    </settings>
  </oracle.dataaccess.client>
</configuration>

Wenn Sie ODP.Net auf dem Zielcomputer installieren, sollte das Problem behoben sein. Das Kopieren der DLLs ist keine gute Idee.

Für Oracle 11g (11.1.0.7.20) musste ich die folgenden DLLs zusammen mit meiner Exe hinzufügen, um zu funktionieren.

1. oci.dll
2. OraOps11w.dll
3. oraociicus11.dll (ziemlich groß in der Nähe von 30 MB)
4. Oracle.DataAccess.dll

Es scheint mir, dass der ODP, obwohl Sie ODP mit dem Oracle Istant Client haben, möglicherweise versucht, stattdessen den tatsächlichen Oracle Client zu verwenden. Haben Sie auch einen Standard-Oracle-Client auf dem Computer installiert? Ich erinnere mich, dass Oracle ziemlich wählerisch war, wenn es um mehrere Clients auf demselben Computer ging.

Ich hatte genau das gleiche Problem. Ich habe oraociei11.dll nach dem Kompilieren der Anwendung gelöscht (und vergessen, dass ich gelöscht hatte). Und es gab diesen Fehler beim Versuch, auszuführen. Wenn die DLL oraociei11.dll nicht gefunden werden kann, wird dieser Fehler angezeigt. Es kann andere Fälle geben, in denen dieser Fehler auftritt, aber dies scheint einer von ihnen zu sein.

Suchen Sie auch nach dem IIS-Anwendungspool. Aktivieren Sie das 32-Bit-Flag "Wahr" oder "Falsch". Wenn Sie diese Meldung sehen, hat mich ein Orakelforum dazu angewiesen!

Ich habe das gleiche Problem, aber in meinem Fall kann ich die DLLs nicht einfach in den Ordner bin kopieren, sondern nur die Assembly-Version neu binden.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>    
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342" culture="neutral"/>
        <bindingRedirect oldVersion="2.112.2.0" newVersion="2.112.1.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Folgendes habe ich getan, um dieses Problem zu lösen, das drei lange Stunden anhielt:

1. Unter Oracle Home unter hatte C:\oracle\product\11.2.0ich einen Ordner namens, client_1in dem ich zuvor ODP.NETBits für Windows 64 Bits installiert hatte .

2. Später beim Versuch, meine ASP.NET-Web-API-App mit Visual Studio 2012 zu debuggen, wurde immer wieder die folgende Fehlermeldung angezeigt: Der Anbieter ist nicht mit der Version des Oracle-Clients kompatibel .

3. Bei der Suche bei Google stellte ich fest, dass dies geschah, weil ich ODP.NET64 Bit verwendete. Dann habe ich ODP.NETnach Windows 32 Bit gesucht und es installiert, aber ich habe immer die gleiche Fehlermeldung erhalten.

4. LÖSUNG: Der Ordner wurde gelöscht client_1und ODP.NET32 Bit neu installiert . Etwas installierte das Installationsprogramm Bits aus der 64-Bit-Version mit der 32-Bit-Version. Stelle dir das vor...

5. Jetzt bin ich wieder glücklich und kann ein neues eröffnen OracleConnection. ENDLICH! :) :)

Für alle, die immer noch dieses Problem haben: basierend auf diesem Artikel

http://oradim.blogspot.com/2009/09/odpnet-provider-is-not-compatible-with.html

Ich habe festgestellt, dass auf meinem Server die Microsoft C ++ Visual Runtime Library fehlt. Ich hatte sie aufgrund des installierten Visual Studio auf meinem Entwicklungscomputer. Ich habe die (aktuell) neueste Version der Bibliothek von hier heruntergeladen und installiert:

http://www.microsoft.com/en-us/download/details.aspx?id=13523

Das Setup lief und der Orakelaufruf von C # hat es geschafft!

TLDR-Version:

• Verwenden Sie stattdessen den zu 100% verwalteten 12c- Anbieter .
• Wenn Sie den alten Anbieter verwenden müssen, müssen Sie Oracle.DataAccess.dll auf die nicht verwalteten Oracle Client-DLLs verweisen, die die richtige Version haben. Wenn Sie mehrere Oracle-Clients auf Ihrem Computer installiert haben, können Sie möglicherweise einfach die Konfigurationsvariable "DllPath" (siehe unten) in Ihre App-Konfiguration aufnehmen. Möglicherweise müssen Sie jedoch auch einen neuen Oracle-Client installieren, auf den Sie verweisen möchten.

Vollversion:

Stellen wir zunächst sicher, dass wir die Komponenten des alten nicht verwalteten Anbieters verstehen (nicht des neuen 12c 100% verwalteten Anbieters). Es besteht aus zwei Teilen:

1. die verwaltete .net-Komponente - Oracle.DataAccess.dll
2. der nicht verwaltete (non.net) Client

Einfach ausgedrückt ist Oracle.DataAccess.dll fast nur ein Wrapper, der .net-Anweisungen in ORACLE-NET-Anweisungen für den nicht verwalteten Client übersetzt.

Das heißt, wenn Sie Oracle.DataAccess laden, gibt es eine Reihenfolge, in der versucht wird, die nicht verwalteten Client-DLLs zu finden, die es benötigt. Aus der Oracle-Dokumentation :

Die Oracle.DataAccess.dll sucht nach abhängigen nicht verwalteten DLLs (z. B. Oracle Client) in der folgenden Reihenfolge:

1.Verzeichnis der Anwendung oder ausführbaren Datei.

2.DllPath-Einstellung, die von der Anwendungskonfiguration oder der web.config angegeben wird.

3.DllPath-Einstellung, die von machine.config angegeben wird.

4.DllPath-Einstellung, die von der Windows-Registrierung angegeben wird.

HKEY_LOCAL_MACHINE \ Software \ Oracle \ ODP.NET \ version \ DllPath

5.Verzeichnisse, die von der Windows-Umgebungsvariablen PATH angegeben werden.

In Ihrem Fall hat Ihre App den oben beschriebenen Vorgang ausgeführt und einen Pfad gefunden, in dem unveränderte DLLs enthalten sind, die im Vergleich zur von Ihnen verwendeten Oracle.DataAccess.dll-Assembly zu alt sind.

Es kann sein, dass die einzige Oracle Client-Installation auf diesem Computer zu alt ist. Dies kommt jedoch ins Spiel, wenn Sie mehr als einen Client auf dem Computer installiert haben und die nicht verwalteten Dateien zuerst in einer anderen, aber älteren Installation gefunden wurden. Wenn dies später der Fall ist, verwenden Sie einfach die Konfigurationsvariable dllPath in Ihrer Konfiguration und zeigen Sie auf den richtigen Oracle Home Bin-Ordner:

<configuration>
  <oracle.dataaccess.client> 
    <add key="DllPath" value="c:\oracle\product\1.1.0-xcopy-dep\BIN"/>
  </oracle.dataaccess.client>
</configuration>

Wenn Sie eine neue Kopie des Clients installieren möchten, verwenden Sie die xcopy-Version die kleinste und enthält den "Instant Client". Zeigen Sie mit dem obigen DllPath auf diesen neuen Speicherort. Aber jede Oracle Client-Installation wird funktionieren.

Wenn Sie jedoch all diese nicht verwalteten Probleme mit der Clientauflösung vermeiden möchten, prüfen Sie, ob Sie Ihre App aktualisieren können, um stattdessen den zu 100% verwalteten Anbieter zu verwenden. Es handelt sich tatsächlich nur um ein oder zwei verwaltete Assemblys, ohne dass eine Abhängigkeit von nicht geänderten Dateien besteht.

Es ist auch möglich, dass Sie die Oracle.DataAccess.dll, die Sie zu sein glauben, nicht laden, wenn sie sowohl in Ihrem bin-Verzeichnis als auch in Ihrem GAC installiert ist, aber ich denke, dass dies das weniger wahrscheinliche Szenario ist. Weitere Informationen finden Sie im Assembly-Auflösungsprozess .

Verfügt der IIS / IWAM-Benutzer über Berechtigungen für das Oracle-Verzeichnis? Können Sie mit einer anderen App wie Excel oder Access eine Verbindung zu dieser Datenquelle herstellen?

Wir hatten das gleiche Problem, da die Oracle.Data.dll-Assembly auf einer Netzwerkfreigabe von unseren Datenbankadministratoren aktualisiert wurde. Durch Entfernen und erneutes Hinzufügen der Referenz aus dem Projekt wurde das Problem behoben.

Nur zwei Schritte, um dieses Problem zu lösen.

1. Gehen Sie zur vorherigen Einstellung des Anwendungspools und setzen Sie das Flag '32-Bit-Anwendung aktivieren' auf True.
2. Stellen Sie sicher, dass alle DLLs in Ihrem Bin jetzt eine 32-Bit-Version sind ...

viel Glück.

Ich bin nicht den Weg gegangen, neue DLLs zu bekommen. Wir hatten eine Reihe bestehender Projekte, die einwandfrei funktionieren, und nur mein neues Projekt bereitete mir Kopfschmerzen, sodass ich mich entschied, etwas anderes auszuprobieren.

Mein Projekt verwendete eine intern entwickelte Internal.dll, die von Oracle.DataAccess.dll abhing v4.112.3.0. Aus irgendeinem Grund wurde Visual Studio beim Veröffentlichen immer hochgeladenv4.121.0.0 , obwohl dies in keiner der Konfigurationsdateien explizit angegeben wurde. Deshalb habe ich einen Fehler bekommen.

Also was ich getan habe war:

1. Kopierte Internal.dll von einem der erfolgreich ausgeführten Projekte auf meine Website /bin(nur um auf der sicheren Seite zu sein).
2. Kopierte Oracle.DataAccess.dll von einem der erfolgreich ausgeführten Projekte auf meine Website /bin.
3. Fügen Sie auf meiner Website einen Verweis auf beide hinzu.
4. Schließlich wurde die Oracle.DataAccess-Referenz in angezeigt myWebSite.csproj, aber es wurde die falsche Version angezeigt : v4.121.0.0anstelle von v4.112.3.0.

5. Ich habe die Referenz manuell geändert myWebSite.csproj, sodass sie jetzt lautet:

   <Reference Include="Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86">
     <SpecificVersion>False</SpecificVersion>
     <HintPath>bin\Oracle.DataAccess.dll</HintPath>
   </Reference> 

Ich bin auf dieses Problem gestoßen, nachdem ich Oracle Data Tools für Visual Studio 2015 installiert und dann eine gute Stunde lang mit Oracle gekämpft habe. Ich habe mich entschlossen, den Oracle-Client erneut zu installieren, anstatt dieses Durcheinander mit dem Kopieren von Dateien, Konfigurationsänderungen usw. zu verursachen, und das hat bei mir funktioniert.

Ich hatte ein ähnliches Problem und die Hauptursache war, dass GAC zwei oracle.dataaccess-Versionen hatte, nämlich v4.0_4.112.2.0 und v4.0_4.112.4.0. Meine Anwendung bezog sich auf v4.0_4.112.2.0. Als ich v4.0_4.112.4.0 aus GAC entfernte, funktionierte sie einwandfrei.

GAC-Pfad: C: \ Windows \ Microsoft.NET \ Assembly \ GAC_64 \ Oracle.DataAccess

Vor :

Nach dem :

Um eine Version zu entfernen, kann man einfach den entsprechenden Ordner aus dem GAC löschen.

Vor kurzem musste ich an einem älteren Projekt arbeiten, bei dem die Lösung und alle enthaltenen Projekte auf die x32-Plattform ausgerichtet waren. Ich habe immer wieder versucht, Oracle.DataAccess.dll und alle anderen vorgeschlagenen Oracle-Dateien an allen Stellen zu kopieren, bin aber jedes Mal gegen die Wand gestoßen. Schließlich leuchtete die Glühbirne im Kopf auf (nach 8 Stunden :)) und bat darum, nach den installierten ODAC-Baugruppen und ihrer Plattform zu suchen. Ich hatte bereits alle 64-Bit-ODAC-Clients (x64) installiert, aber nicht die 32-Bit-ODAC-Clients (x32). Installierte den 32-Bit-ODAC und das Problem verschwand.

So überprüfen Sie die Version des installierten ODAC: Suchen Sie im Ordner C: \ Windows \ Assembly. Die Eigenschaft "Prozessorarchitektur" informiert die Plattform über den installierten ODAC.

Acht Stunden sind eine lange Zeit, in der die Glühbirne aufleuchtet. Kein Wunder, dass ich bei der Arbeit immer schleudern muss :).

Chris 'Lösung hat auch bei mir funktioniert. Ich habe jedoch eine folgende Fehlermeldung erhalten, die besagt:

Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format.

In der Fremdsprache Oraclish bedeutet dies anscheinend, dass Ihr Programm entweder auf alle Plattformen oder auf 32-Bit-Computer abzielt. Ändern Sie einfach Ihre Zielplattform in den Projekteigenschaften in 64-Bit und hoffen Sie auf das Beste.

Ich hatte das gleiche Problem mit Oracle.DataAccess.dll v4.121.2.0. mit 2-Home-Installation (32- und 64-Bit-Versionen). 32-Bit-Version Workerd, 64-Bit-Version nicht.

In meinem Fall (nach 2 Tagen Versuch) stellte ich fest, dass das Problem Berechtigungen für die 64-Bit-Home-Version waren. Viele Verzeichnisse in dieser Version hatten ausschließlich überschriebene Berechtigungen, bei denen die Rolle "Authentifizierte Benutzer" keinen "Lese" -Zugriff hatte, der standardmäßig im übergeordneten Verzeichnis festgelegt ist. Zu diesen Unterverzeichnissen gehörten "bin", "network / admin", "nls", "oracore", "RDBMS" und möglicherweise andere. Ich fand sie durch Herausfiltern des Ergebnisses "ACCESS DENIED" im Dienstprogramm "Process Monitor" (Procmon.exe) von sysinternals. Sobald die Berechtigungen vom übergeordneten Verzeichnis an diese untergeordneten Unterverzeichnisse vererbt wurden, begann alles zu funktionieren.

Ich habe nicht gewusst, wie die Berechtigungen für das gesamte Oracle-Home überschrieben werden sollen, also habe ich sie jeweils für ein Verzeichnis erstellt. Wenn Sie sich jedoch nicht so viele Sorgen um die Sicherheit machen, können Sie sie für das gesamte entsprechende Oracle-Home-Verzeichnis zurücksetzen.

• Kopieren Sie auf einem 64-Bit-Computer "msvcr71.dll" von C: \ Windows \ SysWOW64 in das bin-Verzeichnis für Ihre Anwendung.
• Kopieren Sie auf einem 32-Bit-Computer "msvcr71.dll" von C: \ Windows \ System32 in das Verzeichnis bin für Ihre Anwendung.

http://randomdevtips.blogspot.com/2012/06/provider-is-not-compatible-with-version.html

Viele theoretische Antworten hier, aber hier kommt ein Arbeitsbeispiel mit Code, den Sie sofort kopieren, einfügen und testen können:

1. Ich habe die Oracle Express-Datenbank OracleXE112 installiert, die bereits einige vorinstallierte Demo-Tabellen enthält.
2. Wenn Sie das Installationsprogramm starten, werden Sie nach einem Kennwort gefragt . Ich habe "xxx" als Passwort eingegeben. (nicht in der Produktion verwendet)
3. Mein Server läuft auf dem Computer 192.168.1.158
4. Auf dem Server müssen Sie den Zugriff für den Prozess TNSLSNR.exe in der Windows- Firewall explizit zulassen . Dieser Prozess überwacht Port 1521. Wenn der folgende Code einen Timeout-Fehler enthält, überprüfen Sie Ihre Firewall.
5. OPTION A: Für C # (.NET2 oder .NET4) können Sie ODAC11 herunterladen , von dem Sie Oracle.DataAccess.dll zu Ihrem Projekt hinzufügen müssen. Zusätzlich hängt diese DLL ab von: OraOps11w.dll, oci.dll, oraociei11.dll (130 MB!), Msvcr80.dll. Diese DLLs müssen sich im selben Verzeichnis wie die EXE befinden, oder Sie müssen den DLL-Pfad angeben in : HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\ODP.NET\4.112.4.0\DllPath. Auf 64-Bit-Maschinen schreiben Sie zusätzlich zuHKLM\SOFTWARE\Wow6432Node\Oracle\...
6. OPTION B: Wenn Sie ODAC12 heruntergeladen haben , benötigen Sie Oracle.DataAccess.dll, OraOps12w.dll, oci.dll, oraociei12.dll (160 MB!), Oraons.dll, msvcr100.dll. Der Registrierungspfad lautetHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\ODP.NET\4.121.2.0\DllPath
7. OPTION C: Wenn Sie keine großen DLLs mit mehr als 100 MB möchten, sollten Sie ODP.NET_Managed12.xxxxxxxx.zip herunterladen, in dem sich Oracle.ManagedDataAccess.dllnur 4 MB befinden und eine rein verwaltete DLL ist, die in 32-Bit- und 64-Bit-Prozessen funktioniert und hängt von keiner anderen DLL ab und erfordert keine Registrierungseinträge.
8. Der folgende C # -Code funktioniert für mich ohne Konfiguration auf der Serverseite (nur die Standardinstallation):

using Oracle.DataAccess.Client;
oder
using Oracle.ManagedDataAccess.Client;

....

Zeichenfolge oradb = "Datenquelle = (DESCRIPTION ="
    + "(ADDRESS_LIST = (ADDRESS = (PROTOKOLL = TCP) (HOST = 192.168.1.158) (PORT = 1521))"
    + "(CONNECT_DATA = (SERVER = DEDICATED)));"
    + "Benutzer-ID = SYSTEM; Passwort = xxx;";

using (OracleConnection conn = new OracleConnection (oradb)) 
{
    conn.Open ();
    using (OracleCommand cmd = new OracleCommand ())
    {
        cmd.Connection = conn;
        cmd.CommandText = "TABLESPACE_NAME aus DBA_DATA_FILES auswählen";

        using (OracleDataReader dr = cmd.ExecuteReader ())
        {
            while (dr.Read ())
            {
                listBox.Items.Add (dr ["TABLESPACE_NAME"]);
            }}
        }}
    }}
}}