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

Я новичок в настройке проекта в Visual Studio 2010, но я сделал несколько исследование и по-прежнему не могу точно понять эту проблему вне. У меня есть решение Visual Studio с С++ DLL, ссылающееся на С# DLL. С# DLL ссылается на несколько других DLL, некоторые в моем проекте и на некоторые внешние. Когда я пытаюсь скомпилировать С++ DLL, я получаю это предупреждение:

warning MSB3270: между процессорной архитектурой проекта, создаваемого "MSIL", и процессорной архитектурой ссылки "[внутренняя С# dll]", "x86" было несоответствие.

Он говорит мне перейти в Configuration Manager для выравнивания моих архитектур. С# DLL настроена с целевой платформой x86. Если я попытаюсь изменить это на что-то другое, например Any CPU, он жалуется, потому что одна из внешних DLL, от которой он зависит, имеет платформу target x86.

Когда я смотрю на Configuration Manager, он показывает платформу для моей С# DLL как x86 и для моего проекта на С++ как Win32. Это похоже на правильную настройку; конечно, я не хочу, чтобы проект моего проекта на С++ имел платформу, установленную на x64, которая является единственной другой представленной опцией.

Что я здесь делаю неправильно?

ОТВЕТЫ

Ответ 1

Это предупреждение, похоже, было введено с новой версией Visual Studio 11 Beta и .NET 4.5, хотя я предполагаю, что это возможно было раньше.

Во-первых, это просто предупреждение. Это не должно повредить ничего, если вы просто имеете дело с зависимостями x86. Microsoft просто пытается предупредить вас, когда вы заявляете, что ваш проект совместим с "Any CPU", но у вас есть зависимость от сборки проекта или .dll, которая является либо x86, либо x64. Поскольку у вас есть зависимость x86, технически ваш проект, следовательно, не совместим с любым "процессором" . Чтобы предупредить об этом, вы должны фактически изменить свой проект с "Любой процессор" на "x86". Это очень легко сделать, вот шаги.

  • Перейдите в пункт меню "Конфигурация сборки".
  • Найдите свой проект в списке, в разделе "Платформа" он скажет "Любой процессор"
  • Выберите "Любой процессор" в раскрывающемся списке, а затем выберите <New..>
  • В этом диалоговом окне выберите x86 из раскрывающегося списка "Новая платформа" и убедитесь, что в раскрывающемся списке "Скопировать настройки из" выбран "Любой процессор".
  • Нажмите OK
  • Вам нужно выбрать x86 для конфигураций Debug и Release.

Это заставит предупреждение уйти, а также сообщит, что ваша сборка или проект теперь больше не совместимы с любым "процессором" , а теперь имеют значение x86. Это также применимо, если вы создаете 64-битный проект с зависимостью x64; вместо этого вы просто выберите x64.

Еще одно замечание: проекты могут быть совместимы с любым "процессором" , если они являются чистыми .NET-проектами. Эта проблема возникает только в том случае, если вы вводите зависимость (сторонняя dll или собственный проект на С++), предназначенный для конкретной архитектуры процессора.

Ответ 2

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

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

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

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

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

Ответ 3

Хорошим правилом является "открытые DLL, закрытые EXE", то есть:

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

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

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

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

  • AnyCPU - загружается как сборка x64 или x86, в зависимости от процесса вызова
  • x86 - загружается как сборка x86; не будет загружаться из процесса x64.
  • x64 - загружается как сборка x64; не будет загружаться из процесса x86

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

В дополнение к ответу Дэвида Сакса вам также потребуется перейти на вкладку Build Project Properties и установить Platform Target в x86 для проекта, который предоставляет вам эти предупреждения. Хотя вы можете ожидать, что этот параметр, похоже, не идеально синхронизирован с настройкой в ​​диспетчере конфигурации.

Ответ 7

У меня была эта проблема сегодня, и просто посмотреть на конфигурацию здания в 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, похоже, не увидела его.

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

Ответ 8

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

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

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

Ответ 9

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

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

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

Ответ 10

Для моего проекта у меня есть требование, чтобы иметь возможность создавать как 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"/>

Ответ 11

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

1) выгрузить проект 2) редактировать свойства проекта i.e.csproj 3 > добавить тег

4) Перезагрузка проекта 5) Сделано...

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

Ответ 18

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