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

17

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

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

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

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

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

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

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

    
задан Roman Starkov 07.07.2010 в 15:49
источник

4 ответа

3

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

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

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

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

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

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

Причины:

  1. x86 позволяет упростить отладку - редактировать и продолжать не поддерживается при работе в режиме 64 бит.
  2. Вы никогда не сможете предвидеть, когда в будущем вы добавите ссылку на сборку, которая требует x86, и забудьте правильно протестировать 64 бит, что приведет к неловким ошибкам во время выполнения в 64-разрядных развертываниях.
ответ дан Marek 07.07.2010 в 16:47
4

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

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

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

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

    
ответ дан Jürgen Steinblock 07.07.2010 в 16:55
3

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

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

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

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

    
ответ дан Hans Passant 07.07.2010 в 17:13
  • Раздражающе, микс также создается каждый раз, когда я создаю новый проект, который должен содержаться в существующем решении, даже если обновление не выполняется. Это редкость, но это действительно нервничает каждый раз ... нужно очистить беспорядок новых конфигураций, созданных VS. –  Roman Starkov 11.12.2010 в 16:32
  • Почему бы вам просто не исключить конфигурации AnyCPU вместо того, чтобы бороться с этим снова и снова? –  Hans Passant 11.12.2010 в 17:35
  • Просто примечание. Я всегда удалял конфигурации без проблем с помощью графического интерфейса. Похоже, что он только сломан для vcproj, но не csproj. –  Roman Starkov 01.02.2011 в 19:22
  • @Hans Не уверен, почему я не ответил на это раньше; Я не исключаю AnyCPU, потому что некоторые из них поступают из внешних независимых от платформы библиотек, которые я не могу изменить, а также потому, что многие вещи на самом деле заметно быстрее на AnyCPU на машине x64. –  Roman Starkov 13.06.2011 в 17:28
  • Вы пропустили точку. Это конфигурация, которая бесполезна, фактическая настройка целевой платформы не является. –  Hans Passant 13.06.2011 в 17:48