Donc, si je comprends bien, le problème était que bien qu'Oracle.DataAccess.dll se trouvait dans le même répertoire que l'application, il ne pouvait pas trouver ses homies de niveau inférieur (oci, et al), d'où l'erreur de compatibilité.
Il s'avère que si vous voulez qu'une application fonctionne avec le déploiement ODAC 11 xcopy indépendamment de ce que l'utilisateur peut avoir installé sur sa machine, vous devez faire 2 choses :
- Définissez la variable d'environnement PATH pour le processus. (Je le faisais déjà.)
-
Définissez la variable d'environnement ORACLE_HOME pour le processus. (Je ne faisais pas ça.)
Environment.SetEnvironmentVariable("PATH", Environment.CurrentDirectory + "\\oracle\\11.1\\odac;" + Environment.CurrentDirectory + "\\oracle\\11.1\\odac\\bin;", EnvironmentVariableTarget.Process); Environment.SetEnvironmentVariable("ORACLE_HOME", Environment.CurrentDirectory + "\\oracle\\11.1\\odac", EnvironmentVariableTarget.Process);
MODIF : Il est également important de noter qu'Oracle lancera cette erreur non seulement pour des problèmes environnementaux, mais également si l'un des fichiers est manquant sur la machine cible. J'ai eu la même erreur sur d'autres machines malgré les paramètres d'environnement, car Subversion était configuré pour ignorer les répertoires appelés "bin", de sorte que la DLL OraOps n'était pas copiée sur le client.
