Подтвердить что ты не робот

Рекомендации для решений Visual Studio 2010, которые содержат проекты "Любой процессор" и "x86"

Часто случается, что одно решение С# содержит некоторые проекты, специфичные для x86 (обычно с использованием собственных зависимостей), а другие - "Любой процессор" .

До недавнего времени я всегда заходил в диспетчер конфигурации и следил за тем, чтобы платформа решений была "Any CPU". Это не слишком большая проблема; это требует особых трюков как упомянутых здесь, но в целом не так уж плохо.

Однако, я недавно начал задаваться вопросом, ошибочны ли эти усилия. Я явно против того, чтобы Visual Studio 2010 (и ранее Visual Studio 2008) был разработан для этого. "Смешанные платформы" на самом деле являются точным описанием, и, хотя изначально он чувствует, что что-то не так, при дальнейших размышлениях я должен сделать вывод, что он не более прав, чем "Любой процессор" .

Итак, в последнее время я пытаюсь выбирать между сохранением "Смешанных платформ" или заменой на "x86" в качестве платформы решений в таких случаях. Последнее отражает намерение: окончательный EXE файл - x86 и работает в 32-битном режиме на 64-битных операционных системах. Первое - это то, что Visual Studio действительно хочет, чтобы это было.

По вашему опыту, есть ли какая-то конкретная платформа решений, которая больше подходит для других в этой ситуации?

Примечание 1: в каждом случае, с которым я столкнулся, "x86" оправдывается родными зависимостями, а "Любой процессор" оправдан, будучи внешней библиотекой, которая действительно не зависит от платформы.

Примечание 2: если я правильно понимаю, платформа решений не имеет большого значения; это просто имя. Кажется, что при добавлении новых проектов по умолчанию изменяется статус "строить-или не строить", но это единственный эффект, который он имеет. Правильно?

4b9b3361

Ответ 1

Имея некоторый опыт с этим, вот что я сейчас думаю:

  • Не имеет никакого значения вообще то, что платформа решений вызывается для проекта с смешанной платформой. Поведение VS точно такое же, что требует такой же суммы очистки после добавления проекта.
  • "Смешанные платформы" немного более точны, поэтому я немного предпочитаю это.

Изменение всего на x86 нежелательно по двум причинам:

  • Некоторые алгоритмы почти в два раза быстрее в режиме x64.
  • Любая общедоступная библиотека, которая является x86, не может использоваться в проекте, который сильно выгоден из режима x64.
  • Поддержание разделяемых библиотек на двух платформах - x86 + x64 - намного больше усилий, чем их сохранение "Любой процессор" и очистка после Visual Studio каждый раз, когда он сбрасывает нежелательные конфигурации решений в решение.

Ответ 2

Объявление Примечание 2: Да. Платформа решений - это всего лишь имя для набора конфигураций проекта, в том числе для создания или отсутствия конкретного проекта.

Я лично использую x86 для всех настольных приложений (для настольных компьютеров, поскольку они развернуты на компьютерах конечных пользователей, на которых обычно не хватает контроля - это намного проще, если вы развертываете серверное приложение на известном сервере).

Причины:

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

Ответ 3

Я только установил мое приложение Windows Forms для запуска как "x86" и все библиотеки классов в проекте как AnyCPU. Если я выполняю приложение все неуправляемые зависимости, даже из библиотеки классов, которые x86 все еще работают.

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

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

С моей точки зрения, лучшее решение.

Ответ 4

Да, это немного беспорядок, с которым вы столкнетесь, когда вы позволяете конвертеру проекта VS2010 импортировать проект из предыдущей версии. Кто не знает. Старые IDE использовали Debug | Любой CPU и Release | Любой CPU в качестве имен конфигурации по умолчанию. VS2010 действительно предпочитает устанавливать платформу Target на x86, потому что среда IDE работает намного лучше, когда вы это делаете. И использует Debug | x86 и Release | x86 в качестве имен конфигурации по умолчанию.

Что создает смесь при импорте старого проекта. И дополнительный набор конфигураций (смешанных платформ), которые вы не просили справиться с беспорядком. Тьфу. Вы также не можете удалить их, кнопка "Удалить" отключена в Configuration Manager.

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

Вы не можете исправить это в среде IDE. Вам нужно будет отредактировать файлы .sln и .vcproj, чтобы избавиться от дополнительных конфигураций и отредактировать имена тех, которые вы хотите сохранить. Или просто держите "Смешанные платформы" в качестве вашей конфигурации по умолчанию и игнорируйте остальные. Просто установите платформу Target на то, что вам нужно, она не должна совпадать с именем конфигурации.