Есть ли недостатки в наличии одного решения на проект?

Question

Мы работаем над большим приложением, включающим около 100 проектов (40 представлений, 40 контроллеров / моделей, 20 библиотек утилит). Мы передали большую часть работы на аутсорсинг, а полученные результаты поступают довольно случайно.

Когда мы получаем результат (проект), нам нужно запустить FxCop, StyleCop, связанные модульные тесты и т. Д., И т. Д., Прежде чем передать его в систему контроля версий. Чтобы сделать это проще, мы обязали каждый проект иметь файл решения. Это позволяет нам просто запустить автоматический сценарий для файла решения, который проверяет его перед регистрацией.

Мой вопрос: «Можете ли вы вспомнить какие-либо недостатки наличия одного решения для каждого проекта?».

Недостатки, которые мы уже обсудили, включают:

1. Дополнительное обслуживание, необходимое разработчикам. Это нас не беспокоит, так как мы взяли на себя разработку по контракту с фиксированной ценой.
2. Привязки SourceSafe в файле решения. Это могло быть огромной проблемой, но, к счастью, мы перешли на TFS около года назад.

Answer 1

Мы находимся в похожей лодке с около 200 проектами, многие из которых являются общими для всех наших решений разных размеров.

Хотя недостатком является время загрузки, одним из преимуществ является отладка, т. Е. Если ваш код обращается к другим сборкам, то хорошо, чтобы все было в одном решении.

Кроме того, мы проводим наши модульные и интеграционные тесты вместе с нашим основным проектом (DLL или EXE) в одном и том же решении, поэтому даже для простого шаблона у нас есть по крайней мере три на решение.

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

С другой стороны: мы не разрешаем проект без решения по причинам, указанным вами выше (запуск FxCop и т. Д.), А также непрерывная интеграция. Одним из недостатков большого решения с несколькими проектами является время сборки, но оно помогает узнать, не привели ли к тому, что возмущение компонентом нарушило несвязанное решение / проект.

Answer 2

Мы обнаружили один недостаток в конце.Все наши проекты находятся в Visual Studio 2008. Если мы хотим обновить один проект до Visual Studio 2010, мы поняли, что нам почти наверняка потребуется обновить любой другой проект (поскольку все они, прямо или косвенно, зависят или зависят, друг с другом).