J'essaie d'utiliser le client instantané Oracle ODP.NET 11g (11.1.0.6.20) sur mon projet ASP.net en tant que fournisseur de données, mais lorsque j'exécute la page aspx, j'obtiens un message " Le fournisseur n'est pas compatible avec la version du message d'erreur du client Oracle ". Toute aide serait appréciée.

J'ai référencé le fournisseur de données dans Visual Studio 2005 et le code derrière ressemble à ceci:

using Oracle.DataAccess.Client;
..

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

//Do Something

oOracleConn.Close();

L'erreur de la page ressemble à ceci:

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

J'ai étudié ce problème plus en détail, et vous devez simplement récupérer toutes les DLL appropriées de la même version téléchargée de ODP.Net et les mettre dans le même dossier que votre fichier Exe, car ODP.Net est difficile de ne pas mélanger numéros de version.

J'ai expliqué comment faire cela ici: http://splinter.com.au/using-the-new-odpnet-to-access-oracle-from-c En voici l'essentiel:

• Téléchargez ODP.Net
• Décompressez le fichier
• Décompressez tous les JAR qu'il contient
• Récupérez ces DLL qui viennent d'être décompressées:
  • oci.dll (renommé de «oci.dll.dbl»)
  • Oracle.DataAccess.dll
  • oraociicus11.dll
  • OraOps11w.dll
  • orannzsbb11.dll
  • oraocci11.dll
  • ociw32.dll (renommé de «ociw32.dll.dbl»)
• Mettez toutes les DLL dans le même dossier que votre exécutable C #

Vous devez «ignorer» toutes les discussions sur x86 / x64 ici pour commencer et essayer à la place le pilote géré ODP.NET (si vous utilisez .Net v4 +):

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

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

Pilote géré ou non géré par Oracle ODP.net

Évitez toutes les DLL «non gérées» quelles problèmes d'architecture! : D (à peu près temps Oracle).

Le package NuGet (fonctionne également pour 11g):

La méthode ancienne / manuelle:

Pour plus d'informations sur la conversion à l'utilisation des bibliothèques gérées :

• Tout d'abord, voici une excellente comparaison de code entre géré et non géré : http://docs.oracle.com/cd/E51173_01/win.122/e17732/intro005.htm#ODPNT148
• Assurez-vous d'avoir téléchargé la version ODP.NET, Managed Driver Xcopy uniquement
• À partir du fichier zip téléchargé, copiez et collez dans le répertoire de votre projet:
  • Oracle.ManagedDataAccessDTC.dll
  • Oracle.ManagedDataAccess.dll
• Ajouter une référence à Oracle.ManagedDataAccess.dll
• Assurez-vous que votre exe est publié (ajouté au dossier d'application dans VS2010) avec les deux dll

J'ai uniquement installé le fournisseur de données Oracle pour .NET 2.0 (11.1.0.6.20) et je n'ai pas installé Oracle Instant Client (11.1.0.6.0) .

Je viens de l'installer et l'erreur a disparu!

Cela peut être dû à l'exécution d'un runtime .NET 64 bits sur un client Oracle 32 bits. Cela peut se produire si votre serveur sur lequel vous exécutez l'application 64 bits. Il exécutera l'application .NET avec le moteur d'exécution 64 bits. Vous pouvez définir l'indicateur CPU sur votre projet dans VS pour qu'il s'exécute dans le runtime 32 bits.

Faisons une sorte de résumé:

Le message d'erreur "Le fournisseur n'est pas compatible avec la version du client Oracle" peut être causé par plusieurs raisons.

• Aucun client Oracle n'est installé. Dans ce cas, le message d'erreur est effectivement trompeur.

  Oracle Data Provider for .NET (ODP.NET, ce fichier Oracle.DataAccess.dll) ne sont pas inclus dans le client Oracle Instant, il doit être installé séparément (téléchargement de 32 bits Composants Oracle Data Access (ODAC) ou 64 bits Composants Oracle Data Access ( ODAC) Téléchargements ) ou vous devez sélectionner l'option correspondante dans Oracle Universal Installer (OUI).

  Notez que lors de l'installation du fournisseur de données Oracle> = 12.1, le fournisseur n'est pas automatiquement enregistré dans GAC. Vous devez l'enregistrer manuellement si nécessaire, voir Oracle Doc 2272241.1 .

• La version d'ODP.NET ne correspond pas à la version installée d'Oracle Client. Vous devez vérifier même le numéro de version mineure! Par exemple, la Oracle.DataAccess.dllversion 4.112.3.0 n'est pas compatible avec Oracle Client 11.2.0.4 . Vérifiez attentivement les versions d'ODP.NET et d'Oracle Client. Vous pouvez utiliser sigcheck sur oraociei*.dllet / ou OraOps*w.dllpour obtenir la version d'Oracle Client.

  Soyez conscient des différents schémas de numérotation. Version du fichier 4.112.3.0 moyen: .NET Framework Version 4, Oracle presse 11.2.0.3.x .

  Il existe les versions ODP.NET "1.x", "2.x" et "4.x". Ces chiffres sont liés aux versions 1.0.3705 / 1.1.4322, 2.0.50727 et 4.0.30319 de Microsoft .NET Framework. La version "1.x" était disponible jusqu'à Oracle Client 11.1. La version "4.x" a été introduite avec Oracle Client 11.2

• L'architecture (32 bits ou 64 bits) de ODP.NET ne correspond pas à l'architecture de votre application. Une application 32 bits fonctionne uniquement avec Oracle Client / ODP.NET 32 bits, respectivement une application 64 bits nécessite Oracle Client / ODP.NET 64 bits. (Sauf si vous utilisez le pilote géré ODP.NET )

• La version .NET Framework ne correspond pas. Par exemple, si vous compilez votre application avec Target .NET Framework 2.0, vous ne pouvez pas utiliser ODP.NET version 4.x. La version cible du .NET Framework doit être égale ou supérieure à la version de ODP.NET.

• La version de Oracle.DataAccess.dllsur votre machine de développement (c'est-à-dire la version qui est chargée lors de la compilation) est supérieure à la version sur la machine cible.

• Sachez que cela Oracle.DataAccess.dllpeut être chargé à partir de GAC qui par défaut a la priorité sur tout fichier fourni localement.

Solutions

• Envisagez d'utiliser le pilote géré ODP.NET, il peut être téléchargé à partir de la page Oracle: Téléchargements des composants Oracle Data Access (ODAC) 64 bits . Là, vous n'avez qu'à copier le Oracle.ManagedDataAccess.dllfichier dans le répertoire de votre application, rien d'autre n'est requis. Cela fonctionne à la fois pour 32 bits et 64 bits.

• Dans votre *.csproj, resp. *.vbprojmodifiez votre référence à ODP.NET comme ceci:

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

  Les attributs tels que Version=...ou processorArchitecture=...ne sont pas obligatoires. Votre application chargera le bon en Oracle.DataAccess.dllfonction de l'architecture sélectionnée et du framework .NET cible (à condition qu'il soit installé correctement) -> non vérifié à 100%

• Si vous ne connaissez pas la version d'Oracle Client sur la machine cible (par exemple, il peut s'agir de la machine de votre client): Accédez à la page de téléchargement mentionnée ci-dessus et téléchargez la version la moins XCopy d'Oracle Data Access Components. Extrayez le zip et copiez uniquement le Oracle.DataAccess.dllfichier sur votre machine locale. Dans votre projet VS, faites référence à cette DLL (probablement obsolète). La version de cette DLL est la plus petite version d'ODP.NET avec laquelle votre application fonctionnera. Lorsque vous exécutez votre application, la politique de l'éditeur dans GAC redirige vers la version réellement installée.

• Je ne pense pas que ce soit une approche intelligente de prendre des DLL uniques et de les copier dans certains dossiers. Il peut fonctionner sur une machine "nue", mais si votre machine cible a installé des produits Oracle, il existe un risque élevé de non-concordance de version. Désinstallez tous les produits Oracle de votre machine et effectuez une nouvelle installation. Jetez un œil à Comment désinstaller / supprimer complètement Oracle 11g (client)? il afin d'obtenir une machine vraiment propre.

• Si vous devez travailler avec des applications 32 bits et 64 bits en même temps, suivez ces instructions pour installer les deux versions sur une seule machine:

Hypothèses: Oracle Home est appelé OraClient11g_home1, la version du client est 11gR2.

• Supprimez éventuellement tout client Oracle installé

• Téléchargez et installez Oracle x86 Client, par exemple dans C:\Oracle\11.2\Client_x86

• Téléchargez et installez le client Oracle x64 dans un dossier différent, par exemple pour C:\Oracle\11.2\Client_x64

• Ouvrez l'outil de ligne de commande, accédez au dossier% WINDIR% \ System32, généralement C:\Windows\System32et créez un lien symbolique ora112vers le dossier C:\Oracle\11.2\Client_x64(voir ci-dessous)

• Accédez au dossier% WINDIR% \ SysWOW64, généralement C:\Windows\SysWOW64et créez un lien symbolique ora112vers le dossier C:\Oracle\11.2\Client_x86, (voir ci-dessous)

• Modifiez la PATHvariable d'environnement, remplacez toutes les entrées comme C:\Oracle\11.2\Client_x86et C:\Oracle\11.2\Client_x64par C:\Windows\System32\ora112, respectivement leur \binsous-dossier. Remarque: C:\Windows\SysWOW64\ora112ne doit pas être dans l'environnement PATH.

• Si nécessaire, définissez votre ORACLE_HOMEvariable d'environnement surC:\Windows\System32\ora112

• Ouvrez votre éditeur de registre. Définissez la valeur de registre HKLM\Software\ORACLE\KEY_OraClient11g_home1\ORACLE_HOMEsurC:\Windows\System32\ora112

• Définissez la valeur de registre HKLM\Software\Wow6432Node\ORACLE\KEY_OraClient11g_home1\ORACLE_HOMEsur C:\Windows\System32\ora112(non C:\Windows\SysWOW64\ora112)

• Vous avez terminé! Vous pouvez maintenant utiliser les clients Oracle x86 et x64 de manière transparente ensemble, c'est-à-dire qu'une application x86 chargera les bibliothèques x86, une application x64 charge les bibliothèques x64 sans autre modification sur votre système.

Commandes pour créer des liens symboliques:

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

Quelques notes:

• Les deux liens symboliques doivent avoir le même nom, par exemple ora112.

• Si vous souhaitez installer ODP.NET manuellement par la suite, veillez à sélectionner les dossiers appropriés pour l'installation.

• Malgré leurs noms, le dossier C:\Windows\System32contient les bibliothèques x64, tandis que les bibliothèques C:\Windows\SysWOW64x86 (32 bits). Ne soyez pas confus.

• Il est peut-être judicieux de définir votre TNS_ADMINvariable d'environnement (respectivement les TNS_ADMINentrées du registre) à un emplacement commun, par exemple TNS_ADMIN=C:\Oracle\Common\network.

Après plusieurs heures de dépannage, j'ai trouvé que ce problème était dû à Oracle.DataAccess.dll (v4.0) dans le répertoire bin de mes projets, mais à l'exécution chargeant également Oracle.DataAccess.dll (v2.x) à partir du GAC. La suppression et la lecture de l'entrée Oracle.DataAccess dans les références du projet ont résolu le problème pour moi.

Les autres fichiers mentionnés ici ne semblaient pas nécessaires dans ma situation.

METTRE À JOUR

La cause première de l'erreur «Le fournisseur n'est pas compatible avec la version du client Oracle» est (généralement) que l'assembly géré tente de charger des bibliothèques non gérées qui ne correspondent pas aux versions. Il semble que vous pouvez forcer le pilote Oracle à utiliser les bibliothèques appropriées en spécifiant le chemin de la bibliothèque dans le fichier web.config ¹

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

installez ODP.Net sur la machine cible et cela devrait résoudre le problème ... copier les dll ne semble pas une bonne idée ...

Pour Oracle 11g (11.1.0.7.20), j'ai dû ajouter les dll suivantes avec mon Exe pour fonctionner.

1. oci.dll
2. OraOps11w.dll
3. oraociicus11.dll (assez énorme près de 30 Mo)
4. Oracle.DataAccess.dll

Il me semble que bien que vous ayez ODP avec le client Oracle Istant, l'ODP essaie peut-être d'utiliser le client Oracle réel à la place. Un client Oracle standard est-il également installé sur la machine? Je me souviens qu'Oracle était assez pointilleux lorsqu'il s'agissait de plusieurs clients sur la même machine.

J'ai eu exactement le même problème. J'ai supprimé (et oublié que j'avais supprimé) oraociei11.dll après avoir compilé l'application. Et il donnait cette erreur en essayant d'exécuter. Donc, quand il ne trouve pas la dll qui oraociei11.dll, il affiche cette erreur. Il peut y avoir d'autres cas où il donne cette erreur, mais cela semble être l'un d'entre eux.

Recherchez également le pool d'applications IIS Activer l'indicateur vrai ou faux 32 bits, lorsque vous voyez ce message, un forum oracle m'a dirigé pour cela!

J'ai le même problème mais dans mon cas, je ne peux pas simplement copier les dll dans le dossier bin, alors je ne «relire» que la version d'assemblage.

<?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>

Voici ce que j'ai fait pour résoudre ce problème qui a persisté pendant 3 longues heures:

1. Sous Oracle home situé à C:\oracle\product\11.2.0j'avais un dossier appelé client_1où j'avais précédemment installé des ODP.NETbits pour Windows 64 bits.

2. Plus tard, en essayant de déboguer mon application API Web ASP.NET avec Visual Studio 2012, j'ai continué à recevoir ce message d'erreur: Le fournisseur n'est pas compatible avec la version du client Oracle .

3. En cherchant sur Google, j'ai trouvé que cela se produisait parce que j'utilisais ODP.NET64 bits. Ensuite, j'ai saisi ODP.NETWindows 32 bits et l'ai installé, mais j'ai continué à recevoir le même message d'erreur.

4. SOLUTION: supprimé le dossier client_1et réinstallé ODP.NET32 bits. Un peu, l'installateur mélangeait des bits de la version 64 bits avec la version 32 bits. Allez comprendre...

5. Maintenant, je suis à nouveau heureux et je peux ouvrir un nouveau OracleConnection. ENFIN! :)

Pour toute personne ayant encore ce problème: basé sur cet article

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

J'ai découvert que mon serveur manquait la bibliothèque Microsoft C ++ Visual Runtime - je l'avais sur ma machine de développement en raison de l'installation de Visual Studio. J'ai téléchargé et installé la version (actuellement) la plus récente de la bibliothèque à partir d'ici:

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

Ran la configuration et l'appel oracle de C # l'a fait!

Version TLDR:

• Utilisez plutôt le fournisseur géré à 100% 12c .
• Si vous devez utiliser l'ancien fournisseur, vous devez pointer Oracle.DataAccess.dll vers les DLL client Oracle non gérées qui sont de la version correcte. Si vous avez plusieurs clients Oracle installés sur votre machine, cela peut être simple comme inclure la variable de configuration "DllPath" (voir ci-dessous) dans la configuration de votre application, mais vous devrez peut-être également installer un nouveau client oracle vers lequel pointer.

Version complète:

Tout d'abord, assurez-vous que nous comprenons les composants de l'ancien fournisseur non géré (pas le nouveau fournisseur 12c géré à 100%). Il est composé de deux pièces:

1. le composant .net géré - Oracle.DataAccess.dll
2. le client non géré (non-.net)

Pour parler simplement, Oracle.DataAccess.dll est presque juste un wrapper, traduisant les instructions .net en instructions ORACLE-NET pour le client non géré.

Cela dit, lorsque vous chargez Oracle.DataAccess, il y a un ordre dans lequel il essaie de localiser les DLL client non gérées dont il a besoin. À partir de la documentation Oracle :

Oracle.DataAccess.dll recherche les DLL non gérées dépendantes (comme Oracle Client) dans l'ordre suivant:

1. répertoire de l'application ou de l'exécutable.

Paramètre 2.DllPath spécifié par la configuration de l'application ou web.config.

Paramètre 3.DllPath spécifié par machine.config.

4.DllPath paramètre spécifié par le registre Windows.

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

5.Répertoires spécifiés par la variable d'environnement Windows PATH.

Donc, dans votre cas, votre application a suivi ce processus ci-dessus et a trouvé un chemin contenant des DLL non gérées qui sont trop anciennes par rapport à l'assembly Oracle.DataAccess.dll que vous utilisez.

Il se peut simplement que la seule installation d'Oracle Client sur cette machine soit trop ancienne. Mais cela entre en jeu si vous avez plus d'un client installé sur la machine et que les fichiers non gérés ont été trouvés en premier dans une installation différente mais plus ancienne. Si le plus tard, la chose simple à faire est d'utiliser la variable de configuration dllPath dans votre configuration et de la pointer vers le bon dossier Oracle Home Bin:

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

Si vous souhaitez installer une nouvelle copie du client, la version xcopy est la plus petite et contient le "client instantané" et pointez le DllPath ci-dessus vers ce nouvel emplacement. Mais toute installation de client Oracle fonctionnera.

Mais si vous souhaitez éviter tout ce problème de résolution de client non géré, voyez si vous pouvez mettre à jour votre application pour utiliser le fournisseur géré à 100% à la place - il ne s'agit en réalité que d'un ou deux assemblys gérés, sans aucune dépendance à des fichiers non gérés.

Il est également possible que vous ne chargiez pas le fichier Oracle.DataAccess.dll que vous pensez être s'il est installé à la fois dans votre répertoire bin et dans votre GAC, mais je pense que c'est le senario le moins probable. Consultez le processus de résolution de l' assembly pour plus d'informations.

L'utilisateur IIS / IWAM dispose-t-il d'autorisations sur le répertoire Oracle? Pouvez-vous vous connecter à cette source de données à l'aide d'une autre application, telle qu'Excel ou Access?

Nous avons eu le même problème, car l'assembly Oracle.Data.dll sur un partage réseau a été mis à jour par nos DBA. La suppression de la référence du projet et son ajout à nouveau résolvait le problème.

Juste deux étapes pour résoudre ce problème.

1. allez à la configuration avancée du pool d'applications et définissez l'indicateur «Activer l'application 32 bits» sur True.
2. Assurez-vous que toutes les DLL de votre corbeille sont maintenant en version 32 bits ...

bonne chance.

Je n'ai pas cherché à obtenir de nouvelles DLL. Nous avions un tas de projets existants qui fonctionnaient parfaitement bien et c'était seulement mon nouveau projet qui me donnait mal à la tête, alors j'ai décidé d'essayer autre chose.

Mon projet utilisait un Internal.dll développé en interne qui dépendait d'Oracle.DataAccess.dll v4.112.3.0. Pour une raison quelconque, lors de la publication, Visual Studio est toujours téléchargé v4.121.0.0, même s'il n'a pas été explicitement spécifié dans l'un des fichiers de configuration. C'est pourquoi j'obtenais une erreur.

Donc ce que j'ai fait était:

1. Copié Internal.dll à partir de l'un des projets en cours d'exécution avec succès sur mon site Web /bin(juste pour être prudent).
2. Copié Oracle.DataAccess.dll à partir de l'un des projets en cours d'exécution avec succès sur mon site Web /bin.
3. Ajoutez une référence aux deux depuis mon site Web.
4. Enfin, la référence Oracle.DataAccess est apparue dans myWebSite.csproj , mais elle a montré la mauvaise version: v4.121.0.0au lieu de v4.112.3.0.

5. J'ai changé manuellement la référence dans myWebSite.csproj, donc il lit maintenant:

   <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> 

J'ai rencontré ce problème après avoir installé Oracle Data Tools pour Visual Studio 2015, puis me battre avec Oracle pendant une bonne heure. J'ai décidé d'essayer de réinstaller le client Oracle au lieu de ce désordre avec la copie de fichiers, les modifications de configuration, etc., et cela a fonctionné pour moi.

J'ai rencontré un problème similaire et la cause principale était que GAC avait 2 versions oracle.dataaccess, à savoir v4.0_4.112.2.0 et v4.0_4.112.4.0. Mon application faisait référence à la v4.0_4.112.2.0, donc lorsque j'ai supprimé la v4.0_4.112.4.0 de GAC, cela fonctionnait bien.

Chemin d'accès au GAC: C: \ Windows \ Microsoft.NET \ assembly \ GAC_64 \ Oracle.DataAccess

Avant :

Après :

Pour supprimer une version, on peut simplement supprimer le dossier correspondant de GAC.

Récemment, j'ai dû travailler sur un projet plus ancien où la solution et tous les projets contenus étaient destinés à la plate-forme x32. J'ai continué à essayer de copier Oracle.DataAccess.dll et tous les autres fichiers Oracle suggérés à tous les endroits, mais j'ai touché le mur à chaque fois. Enfin l'ampoule dans la tête s'est allumée (après 8 heures :)), et a demandé à vérifier les assemblages ODAC installés et leur plate-forme. J'avais déjà tous les clients ODAC 64 bits (x64) installés, mais pas ceux 32 bits (x32). Installé l'ODAC 32 bits et le problème a disparu.

Comment vérifier la version d'ODAC installé: Regardez dans le dossier C: \ Windows \ assembly. La propriété "Processor Architecture" informera la plate-forme de l'ODAC installé.

Huit heures, c'est long pour que l'ampoule s'allume. Pas étonnant que je doive toujours me battre au travail :).

La solution de Chris a également fonctionné pour moi. J'ai cependant reçu un message d'erreur de suivi indiquant:

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.

Apparemment, dans la langue étrangère d'Oraclish, cela signifie que votre programme cible soit toutes les plates-formes, soit des machines 32 bits. Changez simplement votre plate-forme cible dans les propriétés du projet en 64 bits et espérez le meilleur.

J'ai eu le même problème avec Oracle.DataAccess.dll v4.121.2.0. avec installation à 2 foyers (versions 32 et 64 bits). Version 32 bits workerd, version 64 bits non.

Dans mon cas (après 2 jours d'essais), j'ai trouvé que le problème était les autorisations sur la version 64 bits de la maison. De nombreux répertoires dans cette version avaient exclusivement des autorisations remplacées où le rôle «Utilisateurs authentifiés» n'avait pas d'accès «Lecture», qui est défini par défaut sur le répertoire parent. Ces sous-répertoires comprenaient "bin", "network / admin", "nls", "oracore", "RDBMS" et peut-être d'autres. Je les ai trouvés en filtrant le résultat "ACCÈS REFUSÉ" dans l'utilitaire "Process Monitor" (Procmon.exe) de sysinternals. Une fois que les autorisations ont été héritées du répertoire parent vers ces sous-répertoires enfants, tout a commencé à fonctionner.

Je n'ai pas quoi remplacer les autorisations sur l'ensemble de la maison oracle, alors je les ai faites un répertoire à la fois, mais je suppose que si vous ne vous souciez pas autant de la sécurité, vous pouvez le réinitialiser sur tout le répertoire de base oracle correspondant.

• Sur un ordinateur 64 bits, copiez «msvcr71.dll» de C: \ Windows \ SysWOW64 dans le répertoire bin de votre application.
• Sur un ordinateur 32 bits, copiez «msvcr71.dll» de C: \ Windows \ System32 dans le répertoire bin de votre application.

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

Beaucoup de réponses théoriques ici, mais voici un exemple de travail avec du code que vous pouvez copier et coller et tester immédiatement:

1. J'ai installé la base de données Oracle Express OracleXE112 qui est déjà livrée avec des tables de démonstration préinstallées.
2. Lorsque vous démarrez le programme d'installation, un mot de passe vous est demandé . J'ai entré "xxx" comme mot de passe. (non utilisé en production)
3. Mon serveur fonctionne sur la machine 192.168.1.158
4. Sur le serveur, vous devez autoriser explicitement l'accès au processus TNSLSNR.exe dans le pare-feu Windows . Ce processus écoute sur le port 1521. Si vous obtenez une erreur de délai d'expiration du code ci-dessous, vérifiez votre pare-feu.
5. OPTION A: Pour C # (.NET2 ou .NET4), vous pouvez télécharger ODAC11 , à partir duquel vous devez ajouter Oracle.DataAccess.dll à votre projet. En outre, cette DLL dépend de: OraOps11w.dll, oci.dll, oraociei11.dll (130 Mo!), Msvcr80.dll. Ces DLL doivent être dans le même répertoire que le fichier EXE ou vous devez indiquer le chemin de DLL dans: HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\ODP.NET\4.112.4.0\DllPath. Sur les machines 64 bits, écrivez en plusHKLM\SOFTWARE\Wow6432Node\Oracle\...
6. OPTION B: Si vous avez téléchargé ODAC12, vous avez besoin d'Oracle.DataAccess.dll, OraOps12w.dll, oci.dll, oraociei12.dll (160 Mo!), Oraons.dll, msvcr100.dll. Le chemin du registre estHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\ODP.NET\4.121.2.0\DllPath
7. OPTION C: Si vous ne voulez pas d'énormes DLL de plus de 100 Mo, vous devez télécharger ODP.NET_Managed12.xxxxxxxx.zip dans lequel vous trouvez Oracle.ManagedDataAccess.dllqui ne fait que 4 Mo et est une DLL gérée pure qui fonctionne dans les processus 32 bits et 64 bits ainsi et ne dépend d'aucune autre DLL et ne nécessite aucune entrée de registre.
8. Le code C # suivant fonctionne pour moi sans aucune configuration côté serveur (juste l'installation par défaut):

using Oracle.DataAccess.Client;
ou
using Oracle.ManagedDataAccess.Client;

....

string oradb = "Source de données = (DESCRIPTION ="
    + "(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.1.158) (PORT = 1521)))"
    + "(CONNECT_DATA = (SERVER = DEDICATED)));"
    + "ID utilisateur = SYSTÈME; Mot de passe = xxx;";

en utilisant (OracleConnection conn = new OracleConnection (oradb)) 
{
    conn.Open ();
    en utilisant (OracleCommand cmd = new OracleCommand ())
    {
        cmd.Connection = conn;
        cmd.CommandText = "sélectionnez TABLESPACE_NAME dans DBA_DATA_FILES";

        en utilisant (OracleDataReader dr = cmd.ExecuteReader ())
        {
            tandis que (dr.Read ())
            {
                listBox.Items.Add (dr ["TABLESPACE_NAME"]);
            }
        }
    }
}