Основываясь на комментариях, это сводится к проблеме X-Y. Вы не можете делать то, что хотите, но причина, по которой вы хотите это сделать, состоит в том, что вы пытаетесь решить неправильную проблему.
Вы используете тесты пользовательского интерфейса в неправильной точке вашего цикла тестирования. Тесты UI не должны запускаться во время сборки, они должны запускаться после выпуска. Изменение вашего тестового проекта должно полностью привести к сборке.
Кто-то разрабатывает тесты пользовательского интерфейса против кода, который еще не находится в управлении источником, что не имеет смысла. Если кто-то пишет тесты против кода, код должен контролироваться источником.
Я предполагаю, что кто-то вручную выдает незафиксированный код на сервер dev, который используется кем-то другим для написания тестов. Не делай этого. Используйте решение для управления реальным выпуском, так как разработчики пишут код, каждая регистрация автоматически развертывается в среду dev/QA. Тогда люди, пишущие тесты UI, будут иметь что-то, что можно было бы опробовать. В чем смысл написания тестов против кода, который находится в таком состоянии, что ответственный за него разработчик даже не уверен, что его стоит контролировать? Это просто приводит к много времени переписывания тестов по мере развития кода.
Предполагая, что вы правильно настроили все, каждая фиксация кода приложения приведет к тому, что текущий набор тестов будет запущен против последней фиксации. Каждая фиксация тестового кода приведет к запуску нового набора тестов против существующего кода приложения. Две вещи (код приложения и тестовый код) должны быть связаны, а должен всегда строить вместе.
И последнее, в основном мнение: тесты UI ужасны и служат очень мало полезности. Они хрупкие, медленные и трудно выдерживают. Я никогда не видел, чтобы комплексный набор пользовательских интерфейсов действительно обеспечивал ценность. Тесты UI лучше всего служат небольшим набором тестов после курения. Бизнес-логика должна быть в первую очередь проверена модулем, с меньшим набором интеграционных тестов для ее резервного копирования.
Почему у вас есть две зависимые папки проекта? Не должны ли они быть частью одного и того же решения? –
создать 2 сборки, построить 1 для проекта 1, который затем запускает сборку 2 для проекта 2, когда она завершается? –
@MrHinsh: Что было бы измениться, если тезисы проектов находятся в рамках одного и того же командного проекта или того же решения? Проблема остается. Мне нужно, чтобы TFS игнорировал check-in из определенного пути/проекта и не запускал сборку. Но не скрывается. Мне нужно, чтобы он был построен с другими проектами, когда они (другой проект) зарегистрированы. –