Вопрос по .net, visual-studio – Как исправить ошибку компиляции Visual Studio, «несоответствие между процессорной архитектурой»?

400

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

warning MSB3270: There was a mismatch between the processor architecture of the project being build "MSIL" and the processor architecture of the reference "[internal C# dll]", "x86".

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

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

Что я здесь не так делаю?

Насколько мне известно, это ошибка в Visual Studio. Я выбираю x64 в качестве целевой платформы, и он говорит мне, что проект собирается для MSIL. Paul McCarthy
Пол, ты вернешься и примешь ответ? Я думаю, что это большой вопрос для многих людей, и у вас есть один действительно хороший ответ от Дэвида. Anthony Mastrean
У меня недостаточно информации, чтобы сделать обоснованное предложение, но щелкните правой кнопкой мыши свое решение - & gt; Порядок сборки проекта и убедитесь, что ваш проект C # собирается до C ++. Если это не так, перейдите на вкладку Зависимости и дайте VS знать, что проект C ++ зависит от проекта C #. lordcheeto
В чем претензия, в частности, когда вы меняете его на Any CPU? lordcheeto
Visual Studio снова дерьмо на это. Платформа в верхней части экрана показывает x64, но в предупреждении говорится, что строящийся проект - "MSIL". Поэтому Visual Studio говорит мне, что между яблоками и апельсинами есть несоответствие, когда я не использую яблоки. Можем ли мы переименовать его в Visual Stupido? Paul McCarthy

Ваш Ответ

18   ответов
0

и использование Nuget и установка компонента, используемого в проекте (SQLite), исправили это! попробуйте установить свой компонент таким образом и проверьте результат

1

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

Вот решение, которое часто работает для меня: установите все на правильную платформу в Configuration Manager (раскрывающийся список активной конфигурации, как обычно говорит Debug, это хороший способ добраться до него) и платформу проекта (в свойствах проекта) , затем построить, а затем установить все обратно на AnyCPU. Иногда мне приходится удалять и повторно добавлять некоторые зависимости (библиотеки DLL в свойствах каждого проекта), а иногда & quot; Выполнять тесты в 32-битном или 64-битном процессе & quot; (дважды щелкните Local.testsettings и перейдите к Hosts) должен быть изменен.

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

3

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

0

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

добро пожаловать в stackoverflow! Вы можете попытаться сфокусировать / переформатировать этот ответ немного?
Это звучит так, как если бы это был хороший вопрос, или сообщение в блоге, или запрос функции на Connect ... на самом деле он не отвечает на этот вопрос.
445

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

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

Go to the Build|Configuration Manager menu item. Find your project in the list, under Platform it will say "Any CPU" Select the "Any CPU" option from the drop down and then select <New..> From that dialog, select x86 from the "New Platform" drop down and make sure "Any CPU" is selected in the "Copy settings from" drop down. Hit OK You will want to select x86 for both the Debug and Release configurations.

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

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

Это очень хорошо может повредить что-то. Любой exe-процессор будет загружен как x64 на 64-битной ОС и не сможет загрузить dll x86. Поэтому, если у вас есть зависимость от конкретной платформы, вам действительно следует правильно настроить свою платформу.
Кажется, что меню Build отсутствует в VS C # 2010 Express. Как мне добраться до этого? Я бы хотел, чтобы они не скрывали вещи.
При этом, я думаю, что ответ Дэвида правильный, это предупреждение дает вам понять, что ваше приложение действительно не AnyCPU. поэтому вы столкнетесь с проблемами, когда в конечном итоге развернете его на неправильной архитектуре.
Только что узнал, как включить меню сборки в Visual Studio 2010 Express: Меню инструментов - & gt; Настройки - & gt; выберите «Настройки эксперта»
Я только что установил RTW Visual Studio 2012 и открыл существующее решение 2010 года и начал видеть то же самое предупреждение, так что оно все еще существует в RTW.
23

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

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

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

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

Вы не документировали ошибки или исключения, связанные с загрузкой DLL. Я не могу вам помочь, если вы не скажете мне, что вы знаете. Удачи с этим.
Я не писал о сбое загрузки, потому что я не был на 100% уверен, что он был подключен, и при дальнейшей отладке, оказывается, нет. Я использую VS2010. Обновленный текст вопроса. Очень жаль за путаницу Paul Eastlund
Вы на самом деле используете VS2010? Также не совсем понятно, что вы не можете загрузить C ++ / CLI DLL. Что такое диагностика? Обновите ваши вопросы с этой важной информацией.
Итак, чтобы быть ясным: я не создаю EXE, я создаю DLL для запуска с чужим EXE. Изменение цели платформы библиотек C # на Any CPU не устраняет предупреждение. Мне интересно, если этоconnect.microsoft.com/VisualStudio/feedback/details/728901/… - Я бы проигнорировал само предупреждение, но на самом деле EXE может загружать C # DLL, но не C ++ DLL, поэтому я считаю, что это реальная проблема. Paul Eastlund
2

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

Во многих отношениях Visual Studio не облегчает компиляцию смеси любых процессоров и сборок, зависящих от архитектуры. Это выполнимо, но часто требуется, чтобы сборка, которая в противном случае была бы «Любой ЦП» должен быть скомпилирован отдельно для x86 и x64, потому что некоторая зависимость-зависимости-где-то имеет две версии.

Уместна ли конфигурация исполняемого файла, так как я получаю ошибку только при попытке создать библиотеки DLL? (Хотя это x86.) Мой компьютер x64. Paul Eastlund
Это исполняемый файл, который определяет, чтоbitness будет использоваться. Если исполняемый файл работает как x64, то все, что он загружает (прямо или косвенно), должно быть x64 или любым процессором. Если исполняемый файл работает как x86, то все, что загружается (прямо или косвенно), должно быть x86 или любым процессором.
2

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

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

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

0

и сценария конвейера SSIS SQL Server 2012 с пакетом обновления 1 (SP1) - до тех пор, пока не установил SQL Server 2012 с пакетом обновления 2 (SP2).

3

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

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

Мне понадобился целый день, чтобы понять это. Большое спасибо! :)
0

Configuration Manager & quot; Выпустить (Смешанная Платформа).

1

которое не так просто разрешить, так как f.csproj построен по команде. к счастьюподделка XML позволяет вам добавить его там.

0

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

54

EXE targets the OS, by specifying x86 or x64. DLLs are left open (i.e., AnyCPU) so they can be instantiated within a 32-bit or a 64-bit process.

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

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

Подробнее о тонкостях сборки сборки смотритеВот, Резюме гласит что-то вроде:

AnyCPU – loads as x64 or x86 assembly, depending on the invoking process x86 – loads as x86 assembly; will not load from an x64 process x64 – loads as x64 assembly; will not load from an x86 process
Хотя правило Густаво является хорошим принципом, его нельзя использовать для решения конкретной проблемы, задаваемой в этом вопросе, поскольку проект уже зависит от сторонней сборки, которая не следует этому правилу (это x86, а не AnyCPU) , Следовательно, пока существует зависимость, вся цепочка проектов должна быть нацелена на x86 и больше ничего.
Это правило имеет смысл для меня. Но рассмотрим следующую ситуацию: Native.dll (x64), используемый NetA.dll (любой ЦП), используемый NetB.dll (любой ЦП), используемый App1.exe (x64). Здесь нет реальной проблемы, но компиляция NetA.dll дает мне предупреждение. Хорошо, так как эта сборка напрямую зависит от Native.dll, я мог бы также пометить ее как x64. Но потом компиляция NetB.dll жалуется. Я хочу сохранить NetB.dll как "Любой процессор" потому что это обычная сборка, используемая в другом приложении с чистой точкой. Я делаю вывод, что мой единственный вариант - подавить / игнорировать предупреждение. Да?
Из-за зависимости от Native.dll вся линия вашего приложения / сборки теперь x64, независимо от того, подавляете вы предупреждение или нет. Хотя подавление работает в вашем сценарии, в будущем могут возникнуть странные ситуации. Например, 1) сборка NetB используется в среде x86, где Nativex64 не будет загружаться, или 2) ваш клиент хочет версию App1.exe для x86, и вы будете скомпилированы счастливо, поскольку NetB помечен как любой ЦП, но опять же Nativex64 вверху стека не будет загружаться
1

на 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"/>
1

unload project edit project properties i.e .csproj

add the following tag:

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

Reload the project

Это не решение проблемы. Это просто отключение предупреждения для конкретного проекта. Но в некоторых случаях я считаю это правильным решением. Спасибо!
127

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

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

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

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

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
@BenVoigt отличная идея в теории, но для того, чтобы VS был процессом x86, нужны сборки x86 для управления такими вещами, как конструктор Windows Forms, даже если ваше приложение будет только 64-битным. Это действительная, но неудачная причина для использования ложного «Любого ЦП». строить.
"Платформа моих проектов - AnyCPU, и я ссылаюсь на библиотеку MS, созданную для AMD64" ... Это НЕПРАВИЛЬНО. Поскольку целевое развертывание всегда 64-битное, вы можете установить платформу на x64, что делает более подходящей ошибку, если ваше 64-битное предположение когда-либо нарушается, а также предотвращает предупреждение.
Единственное другое официальное упоминание MS об этом решении, которое я видел, находится вMicrosoft .NET Framework 4.5 RC Readme file, Странно это было удалено из файла RTM Readme.
@jrh: Затем поместите GUI в проект DLL и соберитеthat как AnyCPU. EXE должен быть отмечен с правильной архитектурой, чтобы соответствовать родным зависимостям. Правильное отделение GUI от логики проходит долгий путь (хотя у него все еще есть свои ограничения, например, когда нативный код рендерит часть GUI, но поддержка конструктора будет проиграна, если вы не создадите сборки всего проекта для обоих х86 и х64)
Это работает, но не для варианта предупреждения: «Ссылочная сборка ... предназначена для другого процессора, чем приложение». Было бы здорово, если бы для этого предупреждения были похожие настройки?
0

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

Похожие вопросы