Сборку .net можно откомпилировать как x86, x64 и AnyCPU (Itanium я трогать не собираюсь).
Вот ни как не могу понять тайный смысл такого обширного выбора. Почему не оставить AnyCPU, ведь CLR ставится на определенную систему, разрядность которой ему известна. В результате при запуске сборки он может откомпилировать под текущую платформу. Зачем же разработчики предусмотрели возможность явно указывать определенную платформу? В каких случаях это реально полезно?

А>В каких случаях это реально полезно?

Например, когда в .Net приложении используется нативная библиотека собранная под 32 бита, а программа запускается на 64-битной ОС. В этом случае, если приложение явно не собрано под x86, то при загрузки библиотеки произойдет ошибка.

Здравствуйте, Аноним, Вы писали:

А>Сборку .net можно откомпилировать как x86, x64 и AnyCPU (Itanium я трогать не собираюсь).
А>Вот ни как не могу понять тайный смысл такого обширного выбора. Почему не оставить AnyCPU, ведь CLR ставится на определенную систему, разрядность которой ему известна. В результате при запуске сборки он может откомпилировать под текущую платформу. Зачем же разработчики предусмотрели возможность явно указывать определенную платформу? В каких случаях это реально полезно?

ну например приложению нужно использовать стороннюю 32х битную длл.

Здравствуйте, Аноним, Вы писали:

А>Сборку .net можно откомпилировать как x86, x64 и AnyCPU (Itanium я трогать не собираюсь).
А>Вот ни как не могу понять тайный смысл такого обширного выбора. Почему не оставить AnyCPU, ведь CLR ставится на определенную систему, разрядность которой ему известна. В результате при запуске сборки он может откомпилировать под текущую платформу. Зачем же разработчики предусмотрели возможность явно указывать определенную платформу? В каких случаях это реально полезно?

Один из примеров, зачем явно указывать разрядность.
Предположим вы используете стороннюю библиотеку, возможно не .Net.
Библиотека есть в двух вариантах, для x64 и x86.

Так вот, если для вашей сборки, использующей стороннюю библиотеку указать AnyCPU, то на x86 машине она будет искать x86 версию, а на x64 соответственно...

Если лично для вас нет разницы x86 или x64, то указывайте x86 и тогда на любой системе будет использоваться версия x86 библиотеки.

Здравствуйте, JohnnyJ, Вы писали:

JJ>Например, когда в .Net приложении используется нативная библиотека собранная под 32 бита, а программа запускается на 64-битной ОС.

Как отмазка — сойдёт, но технически звучит смешно. Ради _потенциальной_ возможности что-то там вызывать, ВЕСЬ ДОТНЕТ должен опять раскорячиваться под архитектурно-зависимые модули?!! Зачем тогда было вообще создавать ДотНЕТ? Жалко было выбрасывать Жабу?
ЕСЛИ уж приспичило вызывать 32-битный код, всё равно этим может заниматься ОС, рантайм, что угодно, т.к. скомпилированный (в MSIL) модуль имеет всю исчерпывающую инфу о внешних DLL. Тем более, что всё равно на 64 битах Винда берёт на себя заботу о 32-битных модулях.

Здравствуйте, Аноним, Вы писали:

забей, нормальные люди всегда используют AnyCPU, а unmanaged thirdparty деплоят инсталлятором, который детектит битность системы и копирует нужные файлы.

Здравствуйте, btn1, Вы писали:

B>Ради _потенциальной_ возможности что-то там вызывать, ВЕСЬ ДОТНЕТ должен опять раскорячиваться под архитектурно-зависимые модули?!!

Эта возможность на практике часто используется.

B>Зачем тогда было вообще создавать ДотНЕТ? Жалко было выбрасывать Жабу?

В 90-х годах MS и Sun конфликтовали по поводу использования Java в продуктах MS, распространения JRE в комплекте с Windows, использования логотипа Java Compatible и т.п.
В MS решили, что проще написать свою Java, с преферансом и блудницами.

B>ЕСЛИ уж приспичило вызывать 32-битный код, всё равно этим может заниматься ОС, рантайм, что угодно, т.к. скомпилированный (в MSIL) модуль имеет всю исчерпывающую инфу о внешних DLL. Тем более, что всё равно на 64 битах Винда берёт на себя заботу о 32-битных модулях.

В одном процессе не могут использоваться одновременно 32-битные и 64-битные библиотеки. Для совместимости с 32-битным нативным кодом нужно запускать 32-битный процесс.

Здравствуйте, Artem Korneev, Вы писали:

AK>Эта возможность на практике часто используется.

Наверное. У меня за 10 лет не возникла ни разу.

AK>В MS решили, что проще написать свою Java, с преферансом и блудницами.

Это-то очевидно. Непонятно то, что затеяв абсолютно новую платформу, скатились в "совместимое" УГ.

AK>В одном процессе не могут использоваться одновременно 32-битные и 64-битные библиотеки.

Ну запускаются же как-то 32-битные проги в 64-битной ОС? (я про архитектуру amd64 в целом). Т.е. цепочка могла быть такая: MSIL-(JIT)->EXE нативной битности->системный посредник(если нужен)->конкретная функция в DLL.

Здравствуйте, btn1, Вы писали:

B>Это-то очевидно. Непонятно то, что затеяв абсолютно новую платформу, скатились в "совместимое" УГ.

Запустите какое-нибудь простейшее .NET-приложение и посмотрите сколько 100% нативных DLL загружено в его адресное пространство.

B>Ну запускаются же как-то 32-битные проги в 64-битной ОС? (я про архитектуру amd64 в целом)

И ?

B>системный посредник(если нужен)

Напоминает:

1. Идея
2. ??????
3. PROFIT!!!

Опишите, пожалуйста, как работает этот Ваш "системный посредник". Подробно и детально.

Здравствуйте, btn1, Вы писали:

B>Ну запускаются же как-то 32-битные проги в 64-битной ОС? (я про архитектуру amd64 в целом).
Совершенно верно. И они используют 32-битные DLL. Причём для работоспособности 32х-битных процессов в 64-битной среде пришлось вложить дофига усилий.
B>Т.е. цепочка могла быть такая: MSIL-(JIT)->EXE нативной битности->системный посредник(если нужен)->конкретная функция в DLL.
Как вы себе представляете этого "системного посредника"? С учётом того, что тупо семантика ассемблерного кода в x64 и в x32 — разная. Процессор отличает один код от другого по флагам в GDT, куда показывает регистр CS. Вкратце — в одном процессе невозможно одновременно держать два вида кода; тем более, что адресные пространства у x32 и у x64 — совершенно разные.

Здравствуйте, Аноним, Вы писали:

А>Вот ни как не могу понять тайный смысл такого обширного выбора.

А в чем проблема-то? Это настройка для нас (спасибо MS!), тебе ее трогать не нужно, оставь в "any cpu".
Когда первый раз напорешься на грабли, тогда поймешь зачем оно.