Проект Visual Studio должен содержаться больше чем в одном решении?
Более важный, чем попросить фрагменты кода, я верю, должен спросить их, для которого продукта управления исходным кодом они используют (убегите из компаний, которые отвечают на "Visual SourceSafe"), и какую методологию они используют: "Гибкий" или "Толпа" отправляет положительные сигналы, CMMI обычно означает, что компания любит бюрократические процессы, если они дают Вам "ха?" тогда Вас предупреждают;)
4 ответа
Нет, используйте столько решений, сколько вам удобно.
Например, у нас есть большое решение, которое объединяет около 53 проектов. Он включает в себя установщик и программу удаления, так что они могут быть удобно созданы нашим сервером сборки, но если я хочу работать с этими приложениями, я загружаю их в их собственные решения (по 1 проекту в каждом), вместо того, чтобы все время загружать 69 других ненужные проекты. У них нет никаких зависимостей от других проектов, поэтому нет никаких проблем сделать это таким образом (действительно, это намного эффективнее, поскольку решение загружается и строится намного быстрее)
Единственное предостережение относительно нескольких решений заключается в том, что вы должны быть осторожны в любом случае, когда вы не создаете зависимость (например, если вы не создаете библиотеку, тогда вам нужно быть осторожным, чтобы он создавался всякий раз, когда его исходный код изменяется, потому что он больше не будет создаваться автоматически для вас)
edit
Чтобы ответить на последнюю часть вашего вопроса (потому что SO принимает вопрос прочтите, пока вы редактируете ответ!), единственная проблема с решениями в VS2005 заключается в том, что он очень медленный с большим количеством проектов в них. VS2008 намного быстрее при загрузке большого решения, но главный удар состоит в том, что чем больше проектов в решении, тем больше времени требуется на сборку (даже если это просто пропуск проектов, которые не необходимо создать, это займет много времени)
Если вы добавите новую конфигурацию решения, просто сделайте одно убер-решение (или просто оставьте существующее!), а затем внесите в него изменения, чтобы они были применены ко всем объектам за один раз. Вам все равно придется добавить эту новую конфигурацию к любым отдельным решениям, которые вы хотите использовать, но если это решения для одного проекта, вы можете просто удалить их, загрузить .csproj, и он будет автоматически перестроен со всеми конфигурациями в Это. И добавление новых конфигураций, вероятно, будет происходить не так часто.
Основные проблемы, связанные с наличием одного проекта в нескольких решениях:
- Если вы вносите изменения в проект, это может вызвать ошибку компиляции в другом решении.
- Решения должны постоянно обновляться, чтобы идти в ногу с изменениями в общих проектах.
Преимущество наличия проекта в каждом используемом решении:
- Легче отлаживать, когда вы можете проследить проблему, сделанную с исходным кодом.
Другой способ сделать это - использовать в каждом решении библиотеки DLL общих проектов, которые им требуются. Затем каждое решение может решить, когда они хотят изменить, какую версию они используют.
Количество проектов в решении не является большой проблемой. Но это замедлит загрузку и построение раствора. У нас есть решения более 50 проектов.
Я тоже работаю в среде, в которой есть много общих проектов, которые используются в нескольких продуктах. Наша политика - одно решение для каждого конечного приложения. Так что общий проект может быть включен в несколько решений. Это хорошо сработало для нас. Общие проекты, хотя и содержатся в отдельных решениях, сопоставляются с одним и тем же расположением репозитория исходного кода. Таким образом, если общий код изменяется, это затрагивает все содержащиеся приложения (наша система непрерывной интеграции) служит проверкой того, что другие приложения не сломаются в результате изменения общего кода.
Чем больше проектов у вас в Решение VS, тем больше времени требуется на загрузку, и это просто звучит сложно, если нужно управлять различными конфигурациями сборки и зависимостями в одном решении.
У нас есть «главное решение», которое содержит более 100 проектов. Это длилось вечно, пока Microsoft не выпустила исправления Intellisense, описанные здесь .
Наша автоматизированная процедура сборки «непрерывной интеграции» всегда создает главное решение. Для разработки я делю «главное решение» на более мелкие решения, которые содержат подмножество связанных проектов. Поддержание этой структуры занимает некоторое время при добавлении новых проектов, но оно того стоит.
Единственная проблема, которую я обнаружил с проектами в нескольких решениях, можно избежать, используя $ (ProjectDir) вместо $ (SolutionDir) в правилах сборки. ,