Почему разработчики .NET предлагают 32-битные / 64-битные версии сборок .NET? - PullRequest
Новая
       13

Почему разработчики .NET предлагают 32-битные / 64-битные версии сборок .NET?

6 голосов
/ 18 января 2009

Иви, время от времени я вижу версии сборки .NET для x86 и x64. Рассмотрим следующую веб-часть для SharePoint . Почему бы разработчику не предложить единственную версию и позволить компилятору JIT разобраться с остальными? Когда я вижу такие предложения, разве просто разработчик решил создать собственное изображение, используя инструмент, такой как ngen , чтобы избежать JIT?

Кто-то, пожалуйста, помогите мне здесь, я чувствую, что упускаю что-то заметное.

Обновлено

Из того, что я получил ниже, предлагаются сборки x86 и x64 по одной или нескольким из следующих причин:

  1. Разработчик хотел избежать JITing и создал собственное изображение своего кода, ориентируясь на данную архитектуру, используя такой инструмент, как ngen.exe.

  2. Сборка содержит специфичные для платформы COM-вызовы, и поэтому нет смысла создавать ее как AnyCPU. В этих случаях сборки, предназначенные для разных платформ, могут содержать разный код.

  3. Сборка может содержать вызовы Win32 с использованием pinvoke, которые не будут переназначены JIT, поэтому сборка должна быть нацелена на платформу, с которой она связана.

Ответы [ 3 ]

6 голосов
/ 18 января 2009

Когда вы компилируете приложение .net, вам нужно выбрать цель платформы в настройках сборки. Возможные варианты: AnyCPU, x86 и x64.

Распространенной ошибкой является указание AnyCPU в проекте, который включает в себя собственные библиотеки DLL, скомпилированные для x86. Это приведет к ошибкам при работе на 64-битных машинах, что является хорошей причиной для тестирования на 64-битной машине.

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

6 голосов
/ 18 января 2009

Если они используют определенный не-.Net API, то для этого может быть две базы кода, идеальным примером являются элементы управления COM.

ngen - еще одна очень веская причина для этого, как вы упоминали.

0 голосов
/ 03 сентября 2013

COM обрабатывает маршалинг и демаршалинг через границы 32/64 бит. Тем не менее, он не предоставляет никакой поддержки для загрузки альтернативного типа двоичного файла в неправильную ширину указателя квартиры.

Многие сборки опираются на собственный код (например, большинство драйверов SQL написаны на C или C ++). Это невероятно очевидно для всего, что использует p / invoke; таким образом, наличие разных скомпилированных и распределенных указателей означает, что пакет для 64-разрядной версии, скорее всего, содержит 64-разрядные собственные библиотеки DLL, а 32-разрядная версия, вероятно, содержит 32-разрядные собственные библиотеки DLL. Это имеет место, даже если 32- и 64-разрядные версии сборки скомпилированы из одного и того же кода.

csc создаст нативные (предварительно JITted) изображения, если вы попросите об этом.

...