Игнорировать определенный файл из ожидающих изменений

Ответ 1

Некоторые части файлов {app,web}.config могут быть делегированы в другой файл. Примечательно <connectionStrings>.

В app.config или web.config:

<connectionStrings configSource="LocalConnectionStrings.config" />

in LocalConnectionStrings.config имеют (<connectionStrings> - корневой элемент):

<connectionStrings>
    <!-- For the application operations. -->
    <add name="Application"
         connectionString="Data Source=server;Initial Catalog=database;Integrated Security=True;Network Library=dbmssocn"
         providerName="System.Data.SqlClient" />
</connectionStrings>

Таким образом, каждый разработчик имеет LocalConnectionStrings.config, который находится в проекте, но не в исходном элементе управления, установленном с их частными настройками, в то время как {web,app}.config имеет общие настройки. К сожалению, это работает только с ограниченным набором системных элементов конфигурации.

Ответ 2

Обходной способ может заключаться в том, чтобы удалить атрибут readonly в web.config в проводнике Windows, а затем отредактировать его в блокноте:

• Он не появится в ожидающем изменения
• Он все еще в источнике контроль

Уродливое, но простое решение.

Ответ 3

Лучшая практика в отношении файлов конфигурации, TFS и различных машин для разработчиков - (подол)...

Все ваши разработчики должны иметь одну и ту же среду разработки. Это единственный способ управлять файлами web.config в TFS, и он имеет много дополнительных преимуществ:

• Nomore ", но он работает на моем компьютере"

• его друг страшен: "Я не понимаю, какие зависимости требуются. Он больше не компилируется".

• Вы не пожалеете знаменитого "Ах, я забыл сказать вам, я изобрел MyWonderfullApplicationConfigSection, и вы должны определить его в своем web.config, но я не буду рассказывать вам".

• Это действительно поможет настроить среду сборки или развертывание.

Хорошо, это не очень просто, я знаю, что разные разработчики любят разные настройки... но это хорошая идея для стандартизации платформы dev. Это действительно того стоит.

Ответ 4

Для нашей работы в VS 2005/2008 мы включили несколько проверок, и мы просто никогда не проверяем файл web.config.

Для беспокойства о том, как пытаться делать фанки, чтобы не иметь что-то в этом флажке, мы просто не проверяем его. В нечетном случае, когда один из этих файлов проверен, ну, это быстро "Эй, ребята, я испортил",.

С другой стороны, вы можете указать TFS исключить файл из исходного элемента управления. Это будет необходимо на всех компьютерах, потому что решения/проекты все равно будут искать этот файл.

http://arcware.net/2007/04/12/how-to-exclude-files-from-tfs-source-control/

Вы также можете изменить файл .SLN/project. Я сделал этот метод с тестированием проектов, где я не хочу, чтобы исправить тесты других людей, чтобы запустить мой собственный, поэтому я удалил свой тестовый проект из TFS, оставив других без изменений.

Ответ 5

Вы можете сделать копию файлов, которые вы не хотите регистрировать, отменить их проверку и заменить их копией. Поскольку изменение было сделано из внешнего VS, оно не будет проверено, поэтому оно не будет в списке ожидающих изменений.

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

Ответ 6

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

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

Ответ 7

Какую версию студии вы используете?

Если вы находитесь в 2010 году, вы можете использовать преобразования веб-конфигурации. Таким образом, вы можете иметь разные файлы web.config в зависимости от среды. Например, разработка, тестирование, производство.

Если вы в 2008 году, у нас обычно был основной файл web.config, указывающий на наш материал для разработки и файл web.production.config, указывающий на производство. Во время развертывания мы удаляем web.config и переименовываем web.production.config.