Win 7 и ODBC с 64 бит

Question

Я занимаюсь разработкой приложения ASP.NET и пытаюсь использовать 64-разрядную версию драйвера ODBC на моей 64-разрядной машине win 7, поскольку на сервере развертывания установлена ​​Windows Server 2008, которая, естественно, является 64-разрядной, поскольку Microsoftрешил не делать 32-битную версию afaik.

Первая проблема была System.Data.Odbc.OdbcException "ОШИБКА [IM014] [Microsoft] [Диспетчер драйверов ODBC] Указанный DSN содержит несоответствие архитектуры между драйвероми приложение ".Несмотря на то, что я работаю на 64-битной операционной системе, компилятор, похоже, решил скомпилировать для 32-битной.После некоторых исследований я изменил целевую платформу на x64 в каждой из моих (собственных) сборок.Я использую NHibernate и Spring.Net, но я где-то читал, что 64-битные не проблема для NHibernate.Я еще не проверял Spring.Net.Началась компиляция.

Я получил несколько предупреждений о том, что практически каждая сборка .net создается для другой платформы, но я снова где-то читал, что могу игнорировать эти предупреждения, и приложение должно работать нормально, потому что среда выполнения (или компилятор?) определит правильную сборку.

Поэтому я сразу же протестировал приложение и получил System.BadImageFormatException (неправильный формат).Это снова было исключением, касающимся проблем с 32/64 битами, хотя каждая из моих сборок скомпилирована как 64-битная.

Я постепенно начинаю ненавидеть 64-битную версию.Шутки в сторону.Сложно ли создать 64-разрядное приложение в 64-разрядной операционной системе для 64-разрядного сервера с 64-разрядными драйверами?

У кого-нибудь есть решение или есть опыт по решению этой проблемы?Я нашел много обходных путей с использованием 32-битных, но это не вариант здесь.Это должно быть 64-битное решение.

Тем не менее я буду продолжать пытаться решить эту проблему для себя.Я напишу любой прогресс здесь.

Обновление: Spring.Net, похоже, работает нормально на 64-битной версии, поскольку сборка "динамически компилируется во время выполнения на архитектуру собственного компьютера".

Answer 1

Я боролся с этой же ошибкой в ​​течение нескольких часов. Мое окружение было немного другим, но ошибка была той же. Я использовал SSRS, построитель отчетов 3 и SQL Server 2008 R2 на Win Server 2008 R2 x64 Box Я мог создавать соединения и успешно их тестировать в SSRS, но когда я использовал их, я получил ошибку выше. Это было решено, когда я создал 32-битный DSN с тем же именем и параметрами.

Answer 2

Я обычно пытаюсь пойти другим путем: если мне не нужны какие-либо встроенные библиотеки in-proc, я использую AnyCPU. Таким образом, финальная программа может использоваться как на x86, так и на x64. Если мне нужны встроенные внутрипроцессные DLL, я всегда выбирал 32-битную версию x86, потому что намного проще заставить ее работать правильно, и ВАЖНО, мне не нужны 64-битные функции. Так почему же 64-битная версия? Я просто захожу в конфигурацию IIS и настраиваю приложение asp.net для работы в 32-битном режиме.

Например, моя текущая среда разработки полностью 64-битная и работает отлично. Но мой рабочий сервер настроен для размещения моего приложения в 32-битном режиме. Работает отлично, 64 битных проблем нет. Я прошу прощения, если этот ответ не подходит для вас, но мне действительно никогда не требовалось 64-битное содержимое в моих приложениях asp.net.

обновление: я использую 32-битный IIS на производственном сервере. Я не уверен, возможно ли настроить asp.net как 32-битный в 64-битном IIS.