2011-02-01 6 views
0

Je développe une application ASP.NET et j'essaie d'utiliser la version de pilote 64 bits d'ODBC sur ma machine win-win 64 bits, car le serveur de déploiement a Windows Server 2008, qui est naturellement en 64 bits, puisque Microsoft a décidé de ne pas faire une version 32 bits afaik.Win 7 et ODBC avec 64 bits

La première était une System.Data.Odbc.OdbcException"ERREUR [IM014] [Microsoft] [ODBC Driver Manager] Le DSN spécifié contient un décalage d'architecture entre le pilote et l'application". Malgré le fait que je développe sur un système d'exploitation 64 bits, le compilateur semble avoir décidé de compiler pour 32 bits. Après quelques recherches, j'ai changé la plate-forme cible en x64 dans chacun de mes (propres) assemblages. J'utilise NHibernate et Spring.Net, mais j'ai lu quelque part que 64 bits n'est pas un problème pour NHibernate. Je n'ai pas encore vérifié Spring.Net. La compilation a commencé. J'ai reçu quelques avertissements que tout assembly .net est construit pour une autre plate-forme, mais j'ai lu quelque part encore que je peux ignorer ces avertissements et que l'application devrait fonctionner correctement parce que le runtime (ou le compilateur?) Va comprendre bon assemblage.

J'ai donc testé l'application immédiatement et j'ai été récompensé par un System.BadImageFormatException (mauvais format). C'était encore une exception en ce qui concerne les problèmes 32/64 bits bien que chacun de mes assemblys est compilé en 64 bits.

Je commence lentement à détester 64 bits. Sérieusement. Est-ce si difficile de construire une application 64 bits sur un système d'exploitation 64 bits pour un serveur 64 bits avec des pilotes 64 bits?

Est-ce que quelqu'un a une solution ou a de l'expérience avec ce problème? J'ai trouvé de nombreuses solutions de contournement avec l'utilisation de 32 bits, mais ce n'est pas une option ici. Ce doit être une solution 64 bits.

Néanmoins, je vais continuer à essayer de résoudre ce problème. Je vais écrire tout progrès ici.

Mise à jour: Spring.Net semble être très bien sur 64 bits depuis l'ensemble est « compilé dynamiquement lors de l'exécution à l'architecture de la machine native ».

Répondre

0

J'essaie généralement d'aller autrement: Si je n'ai pas besoin de DLL in-proc natives, j'utilise AnyCPU. Donc, le programme final peut être utilisé à la fois sur x86 et x64. Si j'ai besoin de DLL in-proc natives, j'ai toujours choisi la version x86 32 bits, car il est beaucoup plus facile de la faire fonctionner correctement, et surtout, je n'ai besoin d'aucune fonctionnalité 64 bits. Alors pourquoi la version 64bit? Je vais juste à la configuration IIS et configurer mon application asp.net pour fonctionner en mode 32 bits.

Par exemple, mon environnement de développement actuel est entièrement en 64 bits et fonctionne parfaitement. Mais mon serveur de production est configuré pour héberger mon application en mode 32 bits. Cela fonctionne parfaitement, pas de problèmes 64 bits. Je m'excuse si cette réponse n'est pas bonne pour vous, mais je n'ai jamais vraiment eu besoin de 64 bits dans mes applications asp.net.

mise à jour: j'utilise 32 bits IIS sur le serveur de production. Je ne suis pas sûr s'il est possible de configurer asp.net en tant que 32bit dans 64bit IIS.

+0

Malheureusement, il s'agit de la compatibilité entre les composants (application <-> pilote 64 bits odbc) plutôt que la substance 64 bits.Mais j'ai lu sur le mode 32 bits, mais je veux plutôt penser à cela en dernier recours. – Robert

1

Je me suis battu avec cette même erreur pendant plusieurs heures. Mon environnement était légèrement différent, mais l'erreur était la même. J'utilisais SSRS, Report Builder 3 et SQL Server 2008 R2 sur un Win Server 2008 R2 x64 Box Je pouvais créer des connexions et les tester avec succès dans SSRS, mais quand je les utiliserais, j'ai eu l'erreur ci-dessus. Il a été résolu quand j'ai créé un DSN 32 bits du même nom et paramètres.

Questions connexes