TFS 2008, удалите файл из управления исходным кодом, но оставьте его в проекте

Вы должны оставить файл в системе контроля версий. В противном случае вы столкнетесь с несколькими проблемами:

• изменения не будут версироваться. 'nuf сказал.
• он не может быть разветвлен или объединен, хотя web.config является одним из файлов, которые, скорее всего, будут различаться между параллельными средами разработки / тестирования / производства
• изменения, которые вы вносите локально, не будут распространяться коллегам, не работающим вручную
• разработчики, настраивающие среду в первый раз, вообще не получат файл
• Командные сборки не будут содержать файл, так же как и ваши развертывания. (разве вы не выполняете развертывание непосредственно с рабочего стола?!)

Обратите внимание, что состояние отдельных файлов полностью хранится на сервере TFS. ('tf properties' сбрасывает эти метаданные, если вам интересно) Только проекты и Решения имеют привязки, фактически записанные в файл. И даже это фиктивные записи, которые говорят VS: «Не беспокойтесь обо мне, просто спросите TFSProvider, он узнает, кто я и где я должен быть». Хотя в системе проектов VS есть много других причуд, доставляющих мне бесконечную головную боль, в данном случае это ваш друг. Не обходите его.

Лучшие варианты:

1. Отредактируйте сценарий сборки, чтобы переключить атрибут только для чтения до / после модификации. Если вы используете скрипт copyifnewer.bat из связанного сообщения в блоге, это должна быть буквально одна дополнительная строка. Даже если вы хотите, чтобы в make-файле MSBuild все было полностью декларативным, с помощью сторонних задач

2. используйте функцию File -> Source Control -> Exclude. После применения этого параметра файл остается под контролем источника, но больше не будет подвергаться автоматическим проверкам / проверкам со стороны активного решения. Другими словами, вы можете редактировать файл локально по своему усмотрению, не затрагивая никого другого, но если вы хотите зафиксировать (или отложить) свои изменения, вам нужно будет сделать это из Source Control Explorer или командной строки.

Преимущество варианта №1 состоит в том, что он позволяет быстро исправить существующую установку. Обратной стороной является поддержка нескольких копий web.config. * По той же причине, почему копирование / вставка кода - это плохо: если вы измените один, вам придется изменить все остальные - или, что еще хуже, забыть и позволить им рассинхронизироваться до тех пор, пока странные ошибки заставляют вернуться к вопросу. Это можно улучшить, изменив процесс так, чтобы была только одна «основная» сеть. config, а дополнительные копии содержат только различия (через механизм текстовых различий, преобразования XSLT, программные манипуляции в Powershell и т. д.). Конечно, это больше работы.

Вариант №2 позволяет избежать проблем №1 с очень небольшими накладными расходами. (сам процесс разработки не изменился; разница лишь в том, как ведет себя пользовательский интерфейс Visual Studio). Это преимущество имеет решающее значение, если вы вообще часто вносите изменения в web.config. Обратной стороной является отсутствие встроенного способа отслеживания вариаций в «главном» файле. Если единственные различия очень простые, например, пара строк подключения, вам может показаться, что проще всего придерживаться одного «мастера» и позволить людям вносить специальные изменения на своих машинах разработчиков. Есть даже инструменты, чтобы сделать это за вас, такие как Проекты веб-развертывания (простой) и Средство развертывания IIS (сложный). В любом случае ваше фактическое развертывание, конечно же, должно быть автоматизировано и с контролем исходного кода! Если требуются более сложные настройки, чем позволяют эти инструменты, вам, вероятно, понадобится гибридный подход «мастер + преобразование», описанный ранее.