Есть ли какие-то соображения, которые необходимо учитывать при запуске программы .net на x64 и x86? - PullRequest
Новая
       39

Есть ли какие-то соображения, которые необходимо учитывать при запуске программы .net на x64 и x86?

14 голосов
/ 28 сентября 2008

Я считаю, что тип архитектуры (x86 против x64) абстрагируется для вас при создании программ .Net, но есть ли другие соображения, которые могут вызвать проблемы?

Ответы [ 7 ]

19 голосов
/ 28 сентября 2008

Остерегайтесь сторонних COM-библиотек или сторонних библиотек .NET, которые тайно выполняют вызовы win32. Вот где у нас были самые большие головные боли.

11 голосов
/ 28 сентября 2008

Из MSDN doco , среди прочих соображений:

Во многих случаях сборки будут работать одинаково на 32-битной или 64-битной CLR. Некоторые причины, по которым программа ведет себя по-разному при запуске 64-разрядным CLR, включают:

  • Структуры, содержащие членов, которые изменить размер в зависимости от платформы, такой как любой тип указателя.

  • Арифметика указателя, которая включает постоянные размеры.

  • Неправильный вызов платформы или COM объявления, которые используют Int32 для обрабатывает вместо IntPtr.

  • Приведение IntPtr к Int32

Кроме того, расположение файлов по умолчанию.

9 голосов
/ 28 сентября 2008

В этой статье есть много хороших вопросов, о которых следует знать: http://osnews.com/story/20330/Windows_x64_Watch_List

Лично у моего босса есть 64-битный компьютер Vista, и я программирую в 32-битном режиме. Мы столкнулись со следующими проблемами:

  • Реестр для 32-битных приложений скрывается (вроде) в папке Wow6432Node. Не все приложения, которые вы использовали для поиска пути в реестре, будут на этом узле (например, SQL Server не будет).

  • SysWow64 в папке C: \ Windows может вызвать проблемы с DLL, находящимися не там, где они нужны (у нас была эта проблема с компонентом лицензирования стороннего производителя).

  • Иногда нужные вам файлы находятся в "C: \ Program Files (x86)", а не в "C: \ Program Files". Отстой тоже.

2 голосов
/ 25 ноября 2008

MSDN опубликовал небольшую статью о проблемах переноса 32-битных приложений в 64-битную среду исполнения.

http://msdn.microsoft.com/en-us/library/ms973190.aspx

Два других блогера ранее писали о 64-битной разработке, когда работали в команде CLR

2 голосов
/ 28 сентября 2008

  • Чтение и запись в 64-битные значения не является потокобезопасным на 32-битной платформе. Чтение 64-битного значения требует двух операций, которые могут быть прерваны переключением контекста. См. Статью MSDN по Threading.Interlocked.Read для получения дополнительной информации.

  • Также полностью согласен с torial 's ответов ! : -)

1 голос
/ 28 сентября 2008

x64 позволит вам адресовать больше памяти, но, учитывая тот же код, он будет использовать больше памяти, чем x86.

0 голосов
/ 29 декабря 2008

По моему опыту портирование приложения Asp.NET было в основном безупречным. Запуск на 32-битной машине и на 64-битной, и никаких проблем не возникает, кроме наличия дополнительной памяти. Это происходит потому, что многие из уже упомянутых проблем (реестр, многопоточность и т. Д.) Управляются Asp.NET, и вам необходимо правильно исправить их для запуска в среде Asp.NET.

На стороне клиента (в форме Windows) произошло то же самое, но если вы использовали некоторые «небезопасные» API для получения специальных папок или доступа к реестру, то может возникнуть некоторая проблема, как уже указывалось.

С уважением Massimo

...