Проблемы с архитектурой процессора (x86 vs any cpu)

Question

У меня есть библиотека, которая построена для x86. При составлении проектов .NET в «любом процессоре», который ссылается на сборку, я получаю следующее предупреждение компилятора:

"There was a mismatch between the processor architecture of the project being built "MSIL" and 
the processor architecture of the reference "xxx", processorArchitecture=MSIL", "x86". This 
mismatch may cause runtime failures. Please consider changing the targeted processor 
achitecture of your project through the Configuration Manager..." 

У меня есть два проекта. Проекты A и B. Оба проекта .net C# visual studio (2013). Проект A - это сервис Windows, проект B - это простое приложение для форм Windows. Они используют общую библиотеку (также любой процессор), которые снова (иногда) используют библиотеку x86.

Project A (Windows Service, AnyCPU) -> CommonLibrary (AnyCPU) -> UtilityLibrary (x86)

Проект B (WinForms, AnyCPU) -> CommonLibrary (AnyCPU) -> UtilityLibrary (x86)

В Project A я получаю ошибку времени выполнения при использовании UtilityLibrary. Но не из проекта B. Ошибка выполнения в проекте A разрешена после того, как UtilityLibrary встроена в «Any Cpu», или Project A построен на x86, поэтому я знаю, что это связано с этим.

Мой вопрос: В каких случаях возникают ошибки времени использования библиотек, специфичных для архитектуры?

UtilityLibrary является частью недавно выпущенной версии программного обеспечения, а CommonLibrary - это API, также являющийся частью выпуска программного обеспечения. Я пытаюсь определить последствия этого. В будущих выпусках UtilityLibrary будет построен для AnyCpu, так как нет никаких оснований для этого быть X86.

Answer 1

Если вы работаете на 64-разрядной машине, стандартное поведение должно запускать исполняемый файл AnyCPU в 64-разрядном процессе, а не 32-битный процесс. Сборка с пометкой x86 не будет загружаться в 64-битном режиме. .NET Framework предполагает, что есть что-то там, которое является специфичным для архитектуры, и что лучше сообщать о проблеме вверх, а не сбой или делать не то, что происходит при выполнении конкретной архитектуры.

Инструменты сборки предупреждают вас, что это произойдет, если вы запустите его в этом сценарии.

Если вы уверены, что UtilityLibrary не содержит кода, специфичного для процессора, или зависит от всего, что доступно только в виде 32-разрядной библиотеки (например, для ядра базы данных JET), вы можете избежать перекомпиляции, изменив с использованием CorFlags.exe. Необходимая команда:

corflags <path-to-assembly> /32bit- 

В .NET 4.5 появилась новая опция: «Предпочитаете 32-разрядную». Для компилятора C# этот параметр равен /platform:anycpu32bitpreferred. Исполняемый файл, отмеченный этим значением, будет запускаться в 32-разрядном режиме на 64-разрядной машине, если будет 32-разрядная среда выполнения. В Windows 7/Server 2008 R2 и более поздних версиях на самом деле можно удалить слой WOW64, который позволяет запускать 32-разрядные программы. Если вы отметили исполняемый файл как «x86», он не будет запускаться без WOW64, но если вы использовали Any CPU + Prefer 32-bit, он будет работать как 64-разрядный процесс.

По умолчанию для Visual Studio 2013 предусмотрены «Любой процессор» и «Предпочтительно 32-разрядный», для новых проектов Windows Forms и Windows Service. (Протестировано при обновлении 3.) Проекты, обновленные из старых версий Visual Studio, могут иметь разные настройки. Это может объяснить, почему ProjectB работает, пока ProjectA не работает, если ProjectB был создан в более старой версии или если кто-то изменил эту настройку.

Answer 2

Проверьте, что вы строит настройки в деталях. В дополнение к выбору архитектуры есть флажок «Предпочтительный 32 бит». Этот флажок установлен по умолчанию для клиентских приложений Windows, поэтому ваше приложение WinForms работает в 32 бит и работает. Скорее всего, ваша служба Windows не имеет этого, и поэтому работает в 64 бит.