Авторы правы, что существует много камней преткновения для сред с несколькими разработчиками на одном сервере.
Разработчики номер один будут пытаться подключиться к одному и тому же процессу веб-приложений w2ps.exe, поэтому создание отдельных веб-приложений на разных портах является обязательным, если вы не готовы разделить время отладки. Как настроить среду разработки для sharepoint 2013
Вторая проблема - когда вы пытаетесь сотрудничать и использовать общие компоненты / функции. Желание работать отдельно является спорным, я считаю, что разработчики команды должны сотрудничать и делиться, поэтому объединение работы желательно для обеспечения плавной интеграции в единое окончательное решение и чтобы никакая работа не дублировалась. Среда с одним сервером для нескольких разработчиков работает идеально, пока вы не попытаетесь сотрудничать. Одна из распространенных ошибок - использовать один «сервер разработки» для всех разработчиков команды. Если члены команды не работают над совершенно не связанными компонентами и им никогда не нужно выполнять общие действия, такие как перезапуск IIS или присоединение отладчика к процессу IIS, такая среда обычно не работает хорошо ». http://technet.microsoft.com/en-us/magazine/dn145990.aspx Мы совершили эту ошибку из-за недостатка опыта и знаний, но как только вы сделаете это, можно обойти ее.
Моя первая попытка поделиться функциями состояла в том, чтобы скопировать проект разработчика 1 в решение разработчика 2, добавить ссылку на него в проект разработчика 2 и добавить все функции в пакет разработчика 2. Развертывание этого прекрасно работает для разработчика 2, пока, как я обнаружил, если разработчик 1 отсоединяет свое решение от отладчика, он втягивает решение на основе дублированного идентификатора решения из фермы и, следовательно, из веб-приложения каждого разработчика. Поэтому разработчик 2 вытаскивает коврик из-под них. Хотя это частичное решение, и, похоже, оно работает некоторое время, мне потребовалось некоторое время, чтобы разобраться, что происходит и какие комбинации развертываний dev 1 и 2 заставляют друг друга работать, а не работать.
Так что я нашел лучшее решение. В свойствах проекта в Visual Studio на вкладке SharePoint есть поле со списком, называемое «Автоотвод после отладки». Это по умолчанию убирает решение, когда разработчик останавливает подключенный отладчик и извлекает функции из-под других разработчиков. Снятие отметки с этого флажка предотвращает откат и оставляет каждому разработчику отдельные решения, развернутые на уровне фермы, а при повторном подключении к отладчику просто заменяет решение с минимальными усилиями.
По моему опыту, переработка пула приложений IIS настолько быстра, что другие разработчики даже не заметили, но с более крупной командой, чем 2, это могло бы стать более распространенным, так что, возможно, кто-то другой мог бы добавить свой опыт. Я также предполагаю, что если другие разработчики не попытаются присоединиться в то же самое время, когда происходит переработка, это будет хорошо, так что это действительно небольшой шанс перебросить время, и простое отсоединение и повторное подключение исправят это, если это произойдет. когда-либо испытывал.