Всем привет,

У меня очень большой солюшен, который включает около 20 проектов. Общее количество файлов с исходным кодом примерно на 5 мегабайт, общее количество классов около 1500 штук.

Со всей этой махиной я работаю напрямую: открываю солюшен, работаю в нем (редактирую код, и т. д.), потом строю и запускаю весь солюшен целиком. Построение всего солюшена, понятное дело, занимает достаточно много времени. И при малейшем изменении хотя бы одной строки кода происходит перекомпилирование всей этой махины.

Мне же хочется, чтобы все работало так, как работал когда-то Visual Basic 6.0 — с такой же скоростью Как этого добиться?

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

Но тут возникает другая сложность. В моем супер-большом солюшене каждый проект в References содержит ссылки на другие проекты этого же большого солюшена. Если я создам мини-солюшен с двумя проектами из 20, в этих двух проектах нужно будет References настроить уже на 18 сборок (потому что 20 — 2 = 18 проектов в мини-солюшене не будет). Получается, что один и тот же проект в рамках одного солюшена должен иметь references на проекты, а в рамках другого солюшена — на сборки. Придется либо менять постоянно references, при переходе от одного солюшена к другому, либо сделать еще один проект-дублер (файл .csproj). Но неудобство в этом случае будет заключаться в том, что при добавлении в проект нового файла с новыми классами, этот файл нужно будет добавлять сразу в несколько проектов. Надеюсь, что я не слишком путанно объяснил

В общем, общий вопрос — как нормально и эффективно работать с таким огромным солюшеном? Как это делается с больших компаниях ... вроде Microsoft? ))

Спасибо.

Здравствуйте, michag, Вы писали:

M>[]
Для этого есть Configuration Manager. Выберите там только те проекты, которые хотите, чтобы компилировались.

Кстати, 20 проектов — это не так уж и много. На предыдущей работе у нас был solution из 115 и, насколько мне известно, он все еще растет.

Здравствуйте, michag, Вы писали:

M>У меня очень большой солюшен, который включает около 20 проектов. Общее количество файлов с исходным кодом примерно на 5 мегабайт, общее количество классов около 1500 штук.

M>Со всей этой махиной я работаю напрямую: открываю солюшен, работаю в нем (редактирую код, и т. д.), потом строю и запускаю весь солюшен целиком. Построение всего солюшена, понятное дело, занимает достаточно много времени. И при малейшем изменении хотя бы одной строки кода происходит перекомпилирование всей этой махины.

M>Мне же хочется, чтобы все работало так, как работал когда-то Visual Basic 6.0 — с такой же скоростью Как этого добиться?

Сделайте разделение сборок на контрактные (интерфейсы) и на реализацию. соответственно, контрактные сборки добавлются как references к проекту... тогда как реализация лежит где-то отдельно.

Здравствуйте, michag, Вы писали:

Да, как здесь говорили 20 проектов это вовсе не большой солюшен.
В Visual Studio начиная с 2003 Enterprise и во всех более поздних топовых версиях есть специальный тип проекта — ETP (Enterprise Template Project). Предназначен он (помимо всего прочего) для организации иерархии проектов в больших волюшенах. В Solution Explorer он выглядит как папка в которой лежат другие проекты. При помощи ETP очень удобно группировать проекты (например проекты UI, проекты DAL, утилиты, общиее библиотеки. Раскидав проекты по ETP-шкам можно организовать один полный и несколько рабочих неполных солюшенов. При этом когда добавляешь новый проект в ETP, не надо добавлять его в каждый солюшен — солюшены вообще не меняются.
В общем, это общепринятая практика на больших проектах. Кроме того у ETP есть еще масса полезных свойств. Для ETP можно устанавливать политики. Например можно создать ETP шаблон пля проектов бизнес логики, в который можно будет добавлять только проекты типа class libraty на C#.

Здравствуйте, stump, Вы писали:

S>Здравствуйте, michag, Вы писали:

S>Да, как здесь говорили 20 проектов это вовсе не большой солюшен.
S>В Visual Studio начиная с 2003 Enterprise и во всех более поздних топовых версиях есть специальный тип проекта — ETP (Enterprise Template Project). Предназначен он (помимо всего прочего) для организации иерархии проектов в больших волюшенах. В Solution Explorer он выглядит как папка в которой лежат другие проекты. При помощи ETP очень удобно группировать проекты (например проекты UI, проекты DAL, утилиты, общиее библиотеки. Раскидав проекты по ETP-шкам можно организовать один полный и несколько рабочих неполных солюшенов. При этом когда добавляешь новый проект в ETP, не надо добавлять его в каждый солюшен — солюшены вообще не меняются.
S>В общем, это общепринятая практика на больших проектах. Кроме того у ETP есть еще масса полезных свойств. Для ETP можно устанавливать политики. Например можно создать ETP шаблон пля проектов бизнес логики, в который можно будет добавлять только проекты типа class libraty на C#.

Хмм, это звучит очень интересно. Полез в свою студию — но не нашел в ней такого типа проекта. Посмотрел в About — у меня Professional версия студии, а не Enterprise — наверное, дело в этом? А чтобы поставить Enterprise версию, требуется деинсталлировать Professional версию и с нуля поставить Enterprise, или возможно произвести безболезненное быстрое обновление?

Здравствуйте, Дюша, Вы писали:

Д>Здравствуйте, michag, Вы писали:

M>>[]
Д>Для этого есть Configuration Manager. Выберите там только те проекты, которые хотите, чтобы компилировались.

Д>Кстати, 20 проектов — это не так уж и много. На предыдущей работе у нас был solution из 115 и, насколько мне известно, он все еще растет.

А как практически происходила работа с таким солюшеном? Каждый программист открывал этот огромный солюшен, ждал 10 минут, пока все загрузится, потом ждал 10 минут, пока все построится, и т. д.? Или работа происходила как-то более эффективно?

Здравствуйте, Дюша, Вы писали:

Д>Для этого есть Configuration Manager. Выберите там только те проекты, которые хотите, чтобы компилировались.

Если снять для некоторого проекта галочку, это будет означать, что он вообще никогда не будет компилироваться? Или что будет компилироваться в отдельных случаях — например, если в проекте будет изменен код некоторых классов?

Получается, что проекты, для которых галочка снята, нужно компилировать вручную — и при этом построенная сборка, соответствующая проекту, будет автоматически помещена в папку bin/Debug приложения?

Здравствуйте, michag, Вы писали:

M>Если снять для некоторого проекта галочку, это будет означать, что он вообще никогда не будет компилироваться?
Да
M> Или что будет компилироваться в отдельных случаях — например, если в проекте будет изменен код некоторых классов?
Нет. Только если правой кнопкой ткнуть в него и выбрать Build / Rebuild.

M>Получается, что проекты, для которых галочка снята, нужно компилировать вручную — и при этом построенная сборка, соответствующая проекту, будет автоматически помещена в папку bin/Debug приложения?
Да. Типичный пример использования Configuration Manager — это случай, когда в solution есть setup project и не надо его компилить каждый раз, когда изменяется что-то в проекте с продуктом.

Здравствуйте, michag, Вы писали:

M>А как практически происходила работа с таким солюшеном? Каждый программист открывал этот огромный солюшен, ждал 10 минут, пока все загрузится, потом ждал 10 минут, пока все построится, и т. д.?
Обычно создавался маленький solution для конкретного проекта и в него включались references на остальные проекты от которых он зависит. Таким образом работа над какой-то частью продукта подразумевала работу с очень ограниченным кол-вом проектов. Когда нужно было выпустить release, то билдили общий solution, в котором, разумеется, был reference на наш проект.

Надеюсь, не очень запутанно объяснил.

Здравствуйте, Дюша, Вы писали:

Д>Здравствуйте, michag, Вы писали:

M>>А как практически происходила работа с таким солюшеном? Каждый программист открывал этот огромный солюшен, ждал 10 минут, пока все загрузится, потом ждал 10 минут, пока все построится, и т. д.?
Д>Обычно создавался маленький solution для конкретного проекта и в него включались references на остальные проекты от которых он зависит.

Вы имели в виду — references на сборки остальных проектов?

Это абсолютно ясная и понятная модель работы — но в своем изначальном сообщении я интересовался, как решается проблема, когда тот же проект входит в разные солюшены — в "огромный" полный солюшен, и в ряд "рабочих" солюшенов. В рамках одного солюшена проект может иметь ссылки на [b]сборки[b] других проектов, а рамках другого солюшена — на [b]сами проекты[b]. Получается, нужно множить файлы .csproj или как?

Из одного из ответов на мой вопрос я так понял, что подход к ETP способен как-то решить эту проблему — но я пока не разбирался с ETP. Как решается проблем без ETP?

Здравствуйте, michag, Вы писали:

M>Вы имели в виду — references на сборки остальных проектов?
references на сами проекты.

M>В рамках одного солюшена проект может иметь ссылки на сборки других проектов, а рамках другого солюшена — на сами проекты.
Зачем такое разделение? Мы делали везде references на проекты.

M>Получается, нужно множить файлы .csproj или как?
.sln?
Ничего нового сейчас не скажу, лишь попытаюсь рпяснить ситуацию.
Схема такая: допустим, есть 100 проектов, которые объеденены одним solution. В их числе — 15 вспомогательных проектов, которые нужны всегда и которые не меняются каждый день. Берем проект, над которым работаем и создаем новый solution, в котором будут 15+1 проектов. И так для каждого stand-alone project.

Зачем создавать разные .crpoj? Почему нельзя всегда пользоваться ссылкой на проект? Ведь если он изменится, то dll у Вас в локальном solution останется старой.

Здравствуйте, Дюша, Вы писали:

Д>Зачем создавать разные .crpoj? Почему нельзя всегда пользоваться ссылкой на проект? Ведь если он изменится, то dll у Вас в локальном solution останется старой.

Дело в том, что чем больше проектов в солюшене, тем он медленнее работает. А если мы в данный момент редактируем только один из 20 проектов, то остальные 19 не нужны, и в солюшен их можно не включать, а в редактируемом проекте установить ссылки на сборки 19 остальных проектов.

Здравствуйте, michag, Вы писали:

M>Здравствуйте, Дюша, Вы писали:

Д>>Зачем создавать разные .crpoj? Почему нельзя всегда пользоваться ссылкой на проект? Ведь если он изменится, то dll у Вас в локальном solution останется старой.

M>Дело в том, что чем больше проектов в солюшене, тем он медленнее работает
Медленнее открывается и билдится. Но мы вернулись к тому, что я предложил с самого начала. Пометьте в configuration manager все проекты, над которыми Вы не работаете сейчас и не хотите чтоб они перекомпилировались и работать будет быстрее (открываться, конечно, быстрее не станет)..

Здравствуйте, Дюша, Вы писали:

Д>Медленнее открывается и билдится. Но мы вернулись к тому, что я предложил с самого начала. Пометьте в configuration manager все проекты, над которыми Вы не работаете сейчас и не хотите чтоб они перекомпилировались и работать будет быстрее (открываться, конечно, быстрее не станет)..

Да, наверное, именно по этому пути я и пойду. Спасибо за совет )

Здравствуйте, stump, Вы писали:

S>Здравствуйте, michag, Вы писали:

S>Да, как здесь говорили 20 проектов это вовсе не большой солюшен.
S>В Visual Studio начиная с 2003 Enterprise и во всех более поздних топовых версиях есть специальный тип проекта — ETP (Enterprise Template Project).

Подскажи пожалуйста, а есть ли что то подобное для VS2005, у меня Team Suite, но ничего подобного я не нашел. Поиск по MSDN тоже ничего не дал, возможно он называется как то по другому сейчас?

Здравствуйте, shapovalov, Вы писали:

S>Здравствуйте, stump, Вы писали:

S>>Здравствуйте, michag, Вы писали:

S>>Да, как здесь говорили 20 проектов это вовсе не большой солюшен.
S>>В Visual Studio начиная с 2003 Enterprise и во всех более поздних топовых версиях есть специальный тип проекта — ETP (Enterprise Template Project).

S>Подскажи пожалуйста, а есть ли что то подобное для VS2005, у меня Team Suite, но ничего подобного я не нашел. Поиск по MSDN тоже ничего не дал, возможно он называется как то по другому сейчас?

Действительно, только сейчас заметил. В VS2005 вместо ETP сделали т.н. Solution Folders. При конвертации солюшена 2003 в 2005 ETP-шки конвертируются именно в Solution Folders. Но Solution Folder не имеет своего файла (она даже может не иметь соответствующей папки в файловой системе), она принадлежит только одному солюшену. Вместе с этим потеряли такую полезную фичу — возможность формирования больших солюшенов из ETP как из строительных блоков.

Здравствуйте, michag, Вы писали:

M>Дело в том, что чем больше проектов в солюшене, тем он медленнее работает. А если мы в данный момент редактируем только один из 20 проектов, то остальные 19 не нужны, и в солюшен их можно не включать, а в редактируемом проекте установить ссылки на сборки 19 остальных проектов.

При изменении кода одного проекта весь солюшн не стоит ребилдить, а только откомпилировать проект в котором были изменения (Shift+F6 при стандартной раскладке).