Как исправить ошибку компиляции Visual Studio, "несоответствие между архитектурой процессора"?

это очень упрямое предупреждение, и хотя это действительное предупреждение, есть некоторые случаи, когда оно не может быть разрешено из-за использования сторонних компонентов и других причин. У меня аналогичная проблема, за исключением того, что предупреждение связано с тем, что моя платформа проектов-AnyCPU, и я ссылаюсь на библиотеку MS, построенную для AMD64. Это, кстати, в Visual Studio 2010 и, похоже, вводится путем установки VS2012 и .Net 4.5.

Так как я не могу изменить библиотеку MS, на которую я ссылаюсь, и поскольку я знаю, что моя целевая среда развертывания будет только 64-битной, я могу спокойно игнорировать эту проблему.

насчет предупреждения? Microsoft опубликовала в ответ на отчет о подключении что можно отключить это предупреждение. Вы должны сделать это только потому, что вы очень хорошо знаете свою архитектуру решения, и вы полностью понимаете свою цель развертывания и знаете, что это не проблема вне среды разработки.

вы можете редактировать свои файл проекта и добавить эту группу свойств и параметр, чтобы отключить предупреждение:

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

хорошим эмпирическим правилом является "открытые DLL, закрытые EXEs", то есть:

• exe-файла цели ОС, указав x86 или x64.
• библиотеки остаются открытыми (т. е. AnyCPU), поэтому их можно создать в 32-битном или 64-битном процессе.

когда вы создаете EXE как AnyCPU, все, что вы делаете, это откладывать решение о том, какую битность процесса использовать для ОС, которая будет JIT EXE по своему вкусу. То есть, ОС x64 будет создайте 64-разрядный процесс, ОС x86 создаст 32-разрядный процесс.

построение DLL как AnyCPU делает их совместимыми с любым процессом.

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

• любой ЦП – загружается как сборка x64 или x86, в зависимости от процесса вызова
• x86 - загружается как сборка x86; не будет загружаться из x64 процесс
• х64 - загружается как сборка x64; не будет загружаться из процесса x86

DLL C# настраивается с целевой платформой x86

что является своего рода проблемой, DLL на самом деле не может выбрать, какова будет битность процесса. Это полностью определяется проектом EXE, это первая сборка, которая загружается, поэтому ее целевой параметр платформы-это тот, который подсчитывает и устанавливает битность для процесса.

DLL не имеют выбора, они должны быть совместимы с битностью процесса. Если нет затем вы получите большой Kaboom с BadImageFormatException, когда ваш код попытается их использовать.

поэтому хорошим выбором для DLL является AnyCPU, поэтому они работают в любом случае. Это имеет большой смысл для DLL C#, они do работать в любом случае. Но конечно, не ваша DLL смешанного режима C++/CLI, она содержит неуправляемый код, который может работать только тогда, когда процесс работает в 32-разрядном режиме. Вы can получите систему сборки для генерации предупреждений об этом. Это именно то, что у тебя есть. Просто предупреждения, он все еще строится правильно.

просто punt проблема. Установите цель платформы EXE-проекта на x86, она не будет работать с какой-либо другой настройкой. И просто держите все проекты DLL в AnyCPU.

в дополнение к David Sacks ответ, вам также может потребоваться перейти к на Project Properties и set Platform Target to x86 для проекта, который дает вам эти предупреждения. Хотя этого можно ожидать, этот параметр не кажется полностью синхронизированным с параметром в configuration manager.

У меня была эта проблема сегодня, и просто просмотр конфигураций зданий в Visual Studio не помогал, потому что он показал любой процессор для проекта, который не строился, и ссылочного проекта.

затем я посмотрел в csproj указанного проекта и нашел это:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x64</PlatformTarget>

каким-то образом этот PlatformTarget был добавлен в середине изменения конфигурации, и IDE, похоже, не видел его.

удаление этой строки из ссылочный проект решил мою проблему.

для проектов C# цель x86 делает то,что она звучит. Он говорит, что эта сборка поддерживает только архитектуры x86. Так же для 64. Любой процессор, с другой стороны, говорит, что мне все равно, какая архитектура, я поддерживаю оба. Итак, следующие 2 вопроса: (1) какова конфигурация исполняемого файла, который использует эти библиотеки DLL? и (2) Что такое bitness вашей ОС / компьютера? Причина, по которой я спрашиваю, заключается в том, что если ваш исполняемый файл скомпилирован для запуска в 64-битном, то ему нужны все зависимости, чтобы иметь возможность работать в 64-разрядном режиме, а также. Любая сборка процессора должна быть загружена, но, возможно, она ссылается на какую-то другую зависимость, которая может работать только в конфигурации x86. Проверьте все зависимости и зависимости зависимостей, чтобы убедиться, что все "любой процессор "или" x64", если вы планируете запустить исполняемый файл в 64-разрядном режиме. Иначе у тебя будут проблемы.

во многих отношениях Visual Studio не делает компиляцию смеси любого процессора и различные агрегаты зодчества зависимые легкие. Это выполнимо, но часто требуется, чтобы сборка, которая в противном случае была бы "любым процессором", должна быть скомпилирована отдельно для x86 и x64, потому что какая-то зависимость от зависимости где-то имеет две версии.

Если ваша C# DLL имеет зависимости на основе x86, то ваша DLL сама должна быть x86. Я не вижу другого выхода. VS жалуется на изменение его на (например) x64, потому что 64-разрядный исполняемый файл не может загружать 32-разрядные библиотеки.

Я немного смущен конфигурацией проекта C++. Предупреждающее сообщение, которое было предоставлено для сборки, предполагает, что оно было предназначено для AnyCPU, потому что оно сообщило, что платформа, на которую оно нацелено, была [MSIL], но вы указано, что конфигурация для проекта была фактически Win32. Собственное приложение Win32 не должно включать MSIL-хотя, вероятно, потребуется включить поддержку CLR, если оно взаимодействует с библиотекой C#. Поэтому я думаю, что есть несколько пробелов в информации.

могу ли я почтительно попросить вас просмотреть и опубликовать немного более подробную информацию о точной конфигурации проектов и о том, как они взаимосвязаны? Будем рады помочь дальше, если это возможно.

У меня была аналогичная проблема раньше, особенно при добавлении тестового решения к существующему решению x64, например SharePoint. В моем случае это связано с тем, что определенные шаблоны проектов добавляются как определенные платформы по умолчанию.

вот решение, которое часто работает для меня: установите все на правильную платформу в Configuration Manager (раскрывающийся список active configuration, говорит Debug normally, это хороший способ добраться до него) и Project platform (в свойства проекта), затем построить, а затем установить все обратно в AnyCPU. Иногда мне приходится удалять и повторно добавлять некоторые зависимости (DLL в свойствах каждого проекта), а иногда "запускать тесты в 32-битном или 64-битном процессе" (дважды щелкните локальный.testsettings и перейти к хостам) должен быть изменен.

Мне кажется, что это просто установка чего-то, а затем установка его обратно, но, вероятно, за кулисами происходит больше, чем я не вижу. Это работало довольно последовательно для меня в но прошлое.

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

мое решение-вручную отредактировать *.csproj файлы, так что строки, как эти:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

изменить на это:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

вы также можете получить это предупреждение для сборок MS Fakes, которые не так легко разрешить с f.csproj строится по команде. К счастью!--1-->подделки xml позволяет добавить его туда.

Я получал то же предупреждение, что и я:

1. выгрузить проект
2. редактировать свойства проекта i.e .csproj файл

3. добавить следующий тег:

   <PropertyGroup>
       <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
           None
       </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
   </PropertyGroup>
   

4. загрузить проект

должен быть способ сделать .NET EXE / DLL AnyCPU, и любые неуправляемые библиотеки DLL он зависит от скомпилированных как с x86, так и с x64, оба в комплекте, возможно, с разными именами файлов, а затем модуль .NET динамически загружает правильный на основе его архитектуры процессора времени выполнения. Это сделало бы AnyCPU мощным. Если DLL C++ поддерживает только x86 или x64, то AnyCPU, конечно, бессмысленно. Но связывание обеих идей, которые я еще не видел, реализовано, поскольку configuration manager даже не обеспечьте средство построить такой же проект дважды с различными конфигурацией / платформой для множественный связывать позволяющ AnyCPU или даже другим концепциям как любая конфигурация быть возможным.

У меня была аналогичная проблема, вызванная MS UNIT Test DLL. Мое приложение WPF было скомпилировано как x86, но модульный тест DLL (ссылочный EXE-файл) как "любой процессор". Я изменил модульный тест DLL для компиляции для x86 (так же, как EXE), и он был resovled.

У меня было очень похожее предупреждение в моей сборке. Мои проекты были настроены на .NET 4.5, на сервере сборки был установлен Windows 8.1 SDK (для .NET 4.5.1). После обновления моих проектов до целевого .NET 4.5.1 (не было проблемой для меня, было для совершенно нового приложения), я больше не получал предупреждения...

Я решил это предупреждение, изменив "Configuration Manager" на выпуск (смешанная Plataform).

Я получил это предупреждение в Visual Studio 2012 при компиляции задачи сценария конвейера SQL Server 2012 SP1 SSIS-пока я не установил SQL Server 2012 SP2.

У меня была такая же проблема с SQLite открытие соединения, и с помощью Nuget и установка компонента, используемого в project (SQLite) исправлена! попробуйте установить компонент таким образом и проверьте результат