Могу ли я использовать символ прекомпиляции, чтобы определить, какой фрагмент кода будет скомпилирован при переключении целевой платформы в Visual Studio - PullRequest
2 голосов
/ 16 декабря 2009

Мы можем переключиться на другую цель .NET Framework в Visual Studio после 2008 года.

У меня есть проект, и я хочу собрать 2 разных целевых сборки Frameworks из него. Если моей целевой платформой является 2.0, я хочу, чтобы она собирала некоторый код, и когда я переключаюсь на другую целевую платформу, я хочу, чтобы она строила другой фрагмент кода для использования некоторых новых функций.

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

#if Framework3
<do something>
#else
<do something else>
#endif

Могу ли я?

Ответы [ 3 ]

2 голосов
/ 16 декабря 2009

Да, мы делаем это в MiscUtil . Я не уверен, что вы можете сделать это непосредственно в Visual Studio, так как выбор целевой платформы находится на странице свойств, которая игнорирует текущую конфигурацию. Однако вы можете отредактировать файл проекта напрямую, чтобы получить правильную целевую среду для правильной конфигурации. В частности, вы должны убедиться, что у вас нет ссылок на .NET 3.5 при нацеливании на .NET 2.0. Посмотрите наш основной файл проекта (MiscUtil.csproj) для более подробной информации.

Часть символов препроцессора проста - как только вы получите конфигурацию сборки для .NET 2.0, вы можете добавлять символы препроцессора непосредственно в Visual Studio.

1 голос
/ 16 декабря 2009

Просто определите один из параметров сборки перед компиляцией для каждой версии фреймворка.

  1. Добавить Framework3
  2. Компиляция для .NET Framework 3.5
  3. Изменить на Framework2
  4. Компиляция для .NET Framework 2.0

Это все еще не так автоматизировано, как вы, вероятно, хотите, но, на мой взгляд, это лучше, чем раскомментировать несколько строк.

0 голосов
/ 16 декабря 2009

Да, вы можете установить определенные константы в свойствах проекта. Наилучший способ справиться с этим, imho, - это иметь отдельные файлы проекта, которые совместно используют код, но имеют разные определенные константы. Таким образом, mycode_Framework1.csproj, mycode_Framework2.csproj и т. Д. Вы можете иметь их в одном решении или нет, но если вы это сделаете, это сделает их сборку сразу проще.

...