Le déploiement du serveur Web qui utilise Oracle.DataAccess génère diverses erreurs d'assemblage

Question

Mon ordinateur de développement est Vista x64. J'utilise les services Web WCF pour créer des services Web s'interfaçant à une base de données 10g d'Oracle. Lorsque le développement a démarré, je ne pouvais pas utiliser l'outil de test WCF intégré de VS2008 [WCFTestClient] qui se lance lorsque vous appuyez sur F5 [Go], sur Oracle.DataAccess.dll 32 bits, car j'obtiens l'exception System.BadImageFormatException l'objet Oracle. Donc, dans mon environnement de développement, je suis passé à la version ODP.NET 64 bits pour mon assemblage référencé, et cela fonctionne très bien.

Je peux déployer sur mon IIS local [7], mais seulement si j'utilise le 32 bits Oracle.DataAccess.dll. J'essaye de déployer à un Win2003 [IIS 6] qui a installé .NET 3.5 SP1, et à la base de données d'Oracle 10g installée. Les autres applications Web de ce serveur utilisent avec succès les connexions Oracle.

Si je supprime toutes les références à Oracle.DataAccess du fichier web.config et m'assure qu'il n'y a pas de fichier Oracle.DataAccess.dll dans mon dossier bin /, je peux afficher la page de métadonnées de service par défaut [s], mais l'appel du service via un client SOAP entraîne une erreur:

"Impossible de charger le fichier ou l'assemblage 'Oracle.DataAccess, Version = 10.2.0.100, Culture = Neutre, PublicKeyToken = 89b483f429c47342' ou l'une de ses dépendances. système ne peut pas trouver le fichier spécifié. "

Cependant, si je mets une copie de Oracle.DataAccess.dll dans mon dossier bin /, je reçois.

« Impossible de charger le fichier ou l'assembly « Oracle.DataAccess » ou une de ses dépendances Le situé La définition de manifeste de l'assembly ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040) "

lorsque vous tentez de charger la page .svc dans un navigateur Web.

Si j'ajoute une référence d'assemblage à mon web.config, je reçois une erreur de configuration: « Impossible de charger le fichier ou l'assemblage xxx »

Je suppose que je suis à la recherche d'aide pour comprendre le cache de montage, et que quelqu'un qui a de l'expérience avec ODP.net qui peut m'aider à naviguer dans ce territoire dangereux et à déployer ce service avec succès.

Answer 1

Ok J'ai réussi à le résoudre [en partie], mais je dois quand même savoir POURQUOI cela a causé l'erreur.

J'ai installé ODP.NET 32 bits sur ma machine locale, dans un dossier distinct de l'installation 64 bits. J'ai changé la référence d'assembly dans mon projet VS en Oracle.DataAccess.dll situé dans le dossier odp.net/bin/2.x/.

Maintenant, le message SOAP ne renvoie plus d'erreur.

La question devient maintenant: pourquoi est-ce que mon choix de dll dans mon environnement de développement conduit la DLL qui doit être utilisée dans l'environnement de production? Je veux être en mesure de développer sur 64 bits et de déployer sur un serveur 32 bits sans avoir à changer mes références chaque fois que je veux déployer.

Answer 2

Récemment, j'ai rencontré un problème similaire et trouvé que l'exception System.BadImageFormatException était provoquée en référençant la version 32 bits d'Oracle.DataAccess d'un projet qui spécifiait une plate-forme cible Any/x64. Après avoir défini le projet sur la cible x86 et la configuration IIS 7 pour activer les applications 32 bits (cliquez avec le bouton droit sur le pool d'applications -> Paramètres avancés ...définir "Activer les applications 32 bits" sur true) tout semble fonctionner comme prévu. En outre, here est un lien vers un article expliquant comment exécuter les versions 32 et 64 bits sur différents processus de travail et un autre here expliquant comment faire fonctionner des applications 32 bits sur 64 bits à l'aide de IIS 6.

Answer 3

dans le même problème, et nous avons dû nous contenter d'utiliser la DLL 32 bits faute de meilleure solution. D'après ce que nous avons pu constater, les dll 64 bits d'Oracle sont construites exclusivement pour 64bit. Contrairement à une DLL construite avec "Any", elle n'inclut pas le code objet 32 ​​bits. Ce serait bien, sauf pour le problème supplémentaire que la DLL 32 bits semble ne pas charger à tous sauf si le projet est construit exclusivement pour 32 bits.

Nous avons essayé des douzaines d'itérations de dll 64/32bit et de paramètres de projet, et nous avons été complètement incapables de faire quoi que ce soit à l'exception du projet 32 ​​bits dll/32 bits. À la fin, nous avons dû aller de l'avant avec le projet et cesser d'investir du temps dans ce qui semblait être une lutte sans fin.

Ma suggestion honnête serait d'évaluer des solutions de base de données alternatives, si possible. Mon expérience avec Oracle a été très douloureuse.

Sinon, il suffit de construire en 32 bits. Cela ne devrait pas causer de problèmes.