Comment déterminer quelle version de "Oracle.DataAccess.dll" à inclure
Lors du déploiement de mon formulaire Windows .NET 3.5 dans différents environnements, nous avons rencontré de nombreux problèmes de fournisseur non valides.
Cela fonctionne sur certains et ne fonctionne pas sur d'autres.
Quelqu'un peut-il m'aider s'il vous plaît, comment puis-je déterminer la version de "Oralce.DataAccess.dll" à utiliser, par exemple, 9, 10, 11 ou 9.1. * Ou 10.1. * Ou 11. * ou 12, etc.
Est-ce que cela dépend du serveur sur lequel j'installe une application? OU
Cela dépend-il de la base de données Oracle back-end?
Je partage l'idée d'utiliser le fournisseur géré à 100% . Cela élimine le besoin de connaître les détails que je suis sur le point de discuter. Le seul problème ici est que je pense que vous devrez peut-être passer à .net 4.0.
Version TLDR:
- Utilisez plutôt le fournisseur géré 12c 100%.
- La réponse courte est de ne pas mélanger le fournisseur (Oracle.DataAccess.dll) avec une version différente du client non géré (du moins, pas en arrière).
- Envisagez de reconcevoir pour inclure une couche de service qui élimine le besoin d'avoir le fournisseur Oracle sur le client en premier lieu.
Version complète:
Tout d’abord, assurons-nous de bien comprendre les composants de l’ancien fournisseur non géré (et non le nouveau fournisseur géré à 12%). Il est composé de deux pièces:
- le composant .net géré - Oracle.DataAccess.dll
- 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 essaie de localiser les dll client non gérées dont il a besoin. De la documentation Oracle :
Oracle.DataAccess.dll recherche les DLL non gérées dépendantes (telles que [.____. Comme Oracle Client) en fonction de l'ordre suivant:
1. Répertoire de l'application ou de l'exécutable.
Paramètre 2.DllPath spécifié par application config ou web.config.
Paramètre 3.DllPath spécifié par machine.config.
Paramètre 4.DllPath spécifié par le registre Windows.
HKEY_LOCAL_MACHINE\Software\Oracle\ODP.NET\version\DllPath
5.Répertoire spécifié par la variable d'environnement Windows PATH.
Cela entre en jeu si vous avez plus d'un client installé sur la machine, alors cela pourrait faire partie de votre problème. Si c'est le cas, la chose simple à faire est d'utiliser la variable de configuration dllPath dans votre configuration:
<configuration>
<Oracle.dataaccess.client>
<add key="DllPath" value="c:\Oracle\product\1.1.0-xcopy-dep\BIN"/>
</Oracle.dataaccess.client>
</configuration>
Maintenant, pour répondre directement à votre question - je ne crois pas que Oracle prenne en charge l’incohérence de Oracle.DataAccess.dll avec son client (du moins pas à l’arrière). Votre meilleur choix consiste à installer ODP.net avec votre application, la version xcopy étant la plus petite et contenant le "client instantané". Vous devez également penser à la configuration système minimale requise, par exemple. Le système doit avoir au moins la version X d'odp.net installée. Vous pouvez ensuite compiler avec cette dll minimale et vous appuyer sur la redirection de stratégie d'éditeur lorsqu'un système cible dispose d'une version NEWER du client.
Bien sûr, cela me pousse également à poser des questions sur l'architecture. Prévoyez-vous d'inviter l'utilisateur à créer son compte Oracle? Sinon, vous devez faire attention à la façon dont vous protégez le compte de service partagé que votre application utilisera. Il peut être préférable de passer des appels vers un service Web qui effectue les appels Oracle pour le compte du client, ce qui vous donne une couche de sécurité supplémentaire et simplifie le déploiement de votre client.
La plupart des versions de ODP.net sont rétrocompatibles avec le serveur de base de données - vous pouvez certainement utiliser le fournisseur 11g avec une base de données 10g.
Première précision: Vous avez une base de données Oracle Server (vous l'avez appelée "base de données Oracle back-end") et un Oracle Client (peu importe si celle-ci est installée sur une application serveur , du point de vue Oracle, c’est le client)
La version de ODP.NET (fournisseur de données Oracle pour .NET, c’est-à-dire Oracle.DataAccess.dll et quelques autres fichiers) est définie par le client Oracle. Vous pouvez utiliser presque toutes les versions d'ODP.NET pour vous connecter à chaque version de base de données Oracle, plus ou moins.
Le message d'erreur "Le fournisseur n'est pas compatible avec la version du client Oracle" peut également signifier qu'aucun fournisseur ODP.NET n'est installé. Dans ce cas, le message d'erreur est en effet un peu trompeur. Donc, vérifiez d’abord si ODP.NET est installé, il n’est pas inclus dans l’installation standard d’Oracle Instant Client.
Lorsque je vérifie tous les téléchargements disponibles d'Oracle, vous avez la version ODP.NET.
- 9. quelque chose
- 10. quelque chose
- 1 fois
- 2.0
- 4.0
9.? et 10.? fait référence à la version d'Oracle, 1.x, 2.0 et 4.0 fait référence à la version de Microsoft .NET Framwork (une numérotation étrange, mais c'est comme ça). Version 9.? et 10.? sont très vieux, je ne pense pas qu'il soit logique de les utiliser. 1.x était pris en charge jusqu'au client Oracle version 11.1.
- Si votre client Oracle est 11.2 ou supérieur, vous devez obligatoirement inclure ODP.NET version 2.0 ou 4.0.
- Si votre client Oracle est compris entre 10.2 et 11.1, vous pouvez utiliser eiter ODP.NET version 1.x ou 2.0.
- Si votre client Oracle a plus de 10 ans, je ne sais pas comment cela fonctionne - il est de toute façon obsolète.
Les versions 1.x et 2.0 ne sont pas compatibles, c’est-à-dire que perhpaps vous devez fournir deux fichiers de configuration différents de votre application à votre client et que celui-ci doit sélectionner le fichier correct en fonction de son installation client Oracle locale.
Je ne connais pas la situation pour 2.0 vs 4.0, je n'ai jamais utilisé 4.0 jusqu'à présent.
Il n'est pas nécessaire de placer une copie locale de Oralce.DataAccess.dll dans le répertoire de votre application. Il sera extrait de GAC (Global Assembly Cache) où il est installé.
Dans votre développement, vous ne devez vous soucier que de ces versions majeures, par exemple 2.0. Ensuite, votre GAC local sait, grâce aux fichiers de règles, quelle version exacte est chargée, par exemple. 2.0.10.2.0.2.20 ou 2.0.11.1.0.6.20 ou 2.0.11.1.0.7.20 ou 2.0.11.2.0.1.2 ou autre.
En plus de tout cela, vous devez savoir si votre client Oracle est 32 bits ou 64 bits et inclure ODP.NET en conséquence.
Vous trouverez ici plus d’informations: Fournisseur de données Oracle pour .NET FAQ
si vous avez une instance client ou Oracle installée sur votre système. vérifier le nom du dossier
Oracle_HOME\product\11.2.0\dbhome_1\ODP.NET\bin\2.x
vous trouverez ici le fichier - Oracle.DataAccess.dll
il suffit d'inclure dans votre référence.
Parfois, vous obtenez le Could not load file or Assembly 'Oracle.DataAccess' or one of its dependencies. alors que vous avez la bonne dll et que le problème se situe ailleurs.
Cela m’arrive (et ce sujet m’a beaucoup aidé à le comprendre) et c’est la configuration de mon pool d’applications dans IIS qui n’autorise pas les applications 32 bits (paramètres avancés).
Si votre serveur Oracle est de version 10.2 ou supérieure, vous pouvez simplement utiliser la version gérée ODP.NET fournie avec Oracle 12.
Apparemment, c'est une dépendance, moins de 10 Mo. Cela devrait faciliter le déploiement de votre application sur différents systèmes par rapport aux versions ODP.NET qui dépendent d’Oracle (instant) Client. Cela devrait également vous éviter de vous soucier de tout client Oracle installé.
Cependant, ils mentionnent que cela fonctionne sur "la dernière version du .NET Framework 4.5.1", donc, si je comprends bien, vous devez mettre à niveau votre application vers la version 4.5.1, mais cela n’est peut-être que si vous voulez utiliser certaines fonctionnalités (comme le support Entity Framework).
http://www.Oracle.com/technetwork/topics/dotnet/index-085163.html
En fait, j’estime qu’il n’ya pas de bonne réponse. Tout dépend de l’architecture du processeur (donc des bits) avec laquelle l’application est exécutée, de la version du client OCI que vous utilisez, etc.
J'ai trouvé très utile de regrouper l'interaction Oracle dans une classe, en utilisant Reflection pour trouver la version disponible à utiliser.
En ce qui concerne le numéro de version: la version des assemblys ODP.net doit correspondre à celle de l'installation du client OCI. Il est déconseillé de mélanger le client OCI 12. * avec les assemblys 10. * ODP.net.
Peut-être que cet article vous est également utile.