Вы должны оставить файл в системе контроля версий. В противном случае вы столкнетесь с несколькими проблемами:
- изменения не будут версироваться. 'Нуф сказал.
- он не может быть разветвлен или объединен, хотя web.config является одним из файлов, которые, скорее всего, будут различаться между параллельными средами разработки / тестирования / производства
- изменения, которые вы вносите локально, не будут распространяться среди коллег без ручных обходных путей
- разработчики, настраивающие среду впервые, вообще не получат файл
- Командные сборки не будут содержать файл, как и ваши развертывания. (конечно, вы не развертываете прямо с рабочего стола ?!)
Обратите внимание, что состояние отдельных файлов полностью хранится на сервере TFS. ('tf properties' сбрасывает эти метаданные, если вам интересно) Только проекты и решения имеют привязки, фактически записанные в файл. И даже это фиктивные записи, которые говорят VS: «Не беспокойтесь обо мне, просто спросите TFSProvider, он узнает, кто я и где я должен быть». Хотя в системе проектов VS есть много других причуд, доставляющих мне бесконечную головную боль, в данном случае это ваш друг. Не обходите это.
Лучшие варианты:
Отредактируйте свой сценарий сборки, чтобы переключить атрибут только для чтения до / после модификации. Если вы используете скрипт copyifnewer.bat из связанного сообщения в блоге, он должен быть буквально одной дополнительной строкой. Даже если вы хотите, чтобы в make-файле MSBuild все было полностью декларативным, с помощью сторонних задач .
Используйте File -> Source Control -> Exclude. После применения этого параметра файл остается под контролем источника, но больше не будет подвергаться автоматическим проверкам / проверкам со стороны активного решения. Другими словами, вы можете редактировать файл локально, сколько душе угодно, не затрагивая никого другого, но если вы хотите зафиксировать (или отложить) свои изменения, вам нужно будет сделать это из Source Control Explorer или командной строки.
Вариант №1 имеет то преимущество, что позволяет быстро исправить существующую настройку. Обратной стороной является поддержка нескольких копий web.config. * По той же причине, почему копирование / вставка кода - это плохо: если вы измените один, вам придется изменить все остальные - или, что еще хуже, забыть и позволить им рассинхронизироваться до тех пор, пока странные ошибки заставляют вернуться к решению проблемы. Это можно улучшить, изменив процесс так, чтобы был только один «главный» файл web.config, а дополнительные копии содержали только различия (через механизм текстовых различий, преобразования XSLT, программные манипуляции в Powershell и т. Д.). Конечно, это больше работы.
Вариант №2 позволяет избежать проблем №1 с очень небольшими накладными расходами. (сам процесс разработки не изменился; разница лишь в том, как ведет себя пользовательский интерфейс Visual Studio). Это преимущество имеет решающее значение, если вы вообще часто вносите изменения в web.config. Обратной стороной является отсутствие встроенного способа отслеживания вариаций в «главном» файле. Если единственные различия очень просты, например, пара строк подключения, вам может показаться, что проще всего придерживаться одного «мастера» и позволить людям вносить специальные изменения на своих машинах разработчиков. Для этого есть даже инструменты, например Проекты веб-развертывания (легко) и Средство развертывания IIS ( сложный). В любом случае ваше фактическое развертывание, конечно же, должно быть автоматизировано и с контролем исходного кода! Если требуются более сложные настройки, чем позволяют эти инструменты, вам, вероятно, понадобится гибридный подход «мастер + преобразование», описанный ранее.
person
Richard Berg
schedule
04.09.2009
