Сборка системы для таргетинга нескольких версий .NET - PullRequest
3 голосов
/ 09 июля 2010

Какова общая практика проектирования системы сборки / структуры проекта, которая позволяет ориентироваться на несколько версий .NET с разными наборами функций?

В частности:

  • Стоит ли переходить в систему контроля версий?
  • Стоит ли использовать условную компиляцию?
  • Должны ли вы получать интерфейсы, тем самым управляя их версиями?
  • Должны ли вы создавать отдельные проекты "versionX" и связывать общие файлы проекта?

1 Ответ

6 голосов
/ 09 июля 2010

Я пробовал несколько разных способов сделать это.

Я исключил ветвление, потому что немного сложно поддерживать синхронизацию всех ветвей с использованием SVN / TFS.Распределенный SCC имеет более продвинутую поддержку ветвления / слияния, поэтому я планирую пересмотреть этот подход, если я когда-нибудь преобразую.

Я использую условную компиляцию вместе с проектами для конкретных версий, использующими связанные исходные файлы.Самая агрессивная библиотека, которую я сделал в этом направлении, - Nito.Linq , которая еще не выпущена.Вы можете проверить источник, чтобы увидеть, как я настроил проекты.Он в настоящее время нацелен на 3.5, 4.0, SL3 и SL4 и имеет варианты «с Rx» и «без Rx» для каждого из них.У меня также работал CF 3.5, но VS2010 его не поддерживает.

У этого подхода есть несколько недостатков:

  • В своем решении я определил «Источники»проект, который действует как контейнер для файлов.К сожалению, он создается при загрузке, и я не могу добавить исходные файлы, когда он выгружен;таким образом, это мешает.
  • Связывание исходных файлов в проектах, нацеленных на разные платформы, вызывает другую проблему: невозможно открыть один и тот же исходный файл в разных проектах.VS сообщит вам об этом, а затем покажет уже открытый исходный файл из другого проекта.Это влияет на IntelliSense, особенно с условной компиляцией.Не ограничитель показа, но много раз вы открываете файл, а затем закрываете его и снова открываете его (а затем возвращаетесь в положение, в котором находились).
  • Модульные тесты на VS2010 имеютнацеливаться на рамки 4.0.Таким образом, любое тестирование на других версиях фреймворка должно выполняться не VS2010.Я еще не нашел хорошего решения для этого;это не влияет на Nito.Linq, потому что модульное тестирование вариантов 4.0 проверяет весь код.

Я спросил команду Rx , как они справились с этой ситуацией (они поддерживают 3.5,4.0, SL3 и SL4 с одинаковой кодовой базой).По-видимому, они используют собственный внутренний инструмент для создания версий сборок только для метаданных, а затем объединяют их в профиль superset, содержащий объединенные сборки только для метаданных.Проект построен на основе этого суперсет-профиля, а после компиляции выполняется «ретаргетинг», чтобы изменить профиль проекта на один из обычных профилей.

Я кратко поиграл с созданиемоткрытый инструмент, эквивалентный инструменту команды Rx, но натолкнулся на слишком много «недокументированных» ошибок.Теоретически это должно быть возможно, но я подумал, что это займет слишком много времени для тех, у кого нет правильных контактов внутри Microsoft.

...