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

ГВ>>Ясно. Нет, я немножко про другое говорю.
ГВ>>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.
ГВ>>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
AN>Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.

Ну да, правильно. Так и должно быть.

ГВ>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.
AN>А на что они еще влияют кроме последовательности сборки/компиляции?

В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.

ГВ>>Тогда, если нам понадобится убрать Lib, чтобы случайно не зацепить его исходники, мы можем просто удалить его из солюшена. Правда, при вставке обратно придётся заново проставить зависимости, поэтому лучше просто сделать новый солюшен — сами .csproj менять при этом не нужно.
AN>Как то сложно представить удобство переключения солюшен,

Alt-Tab

AN>да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?

"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.

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

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

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

ГВ>>>Ясно. Нет, я немножко про другое говорю.
ГВ>>>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.
ГВ>>>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
AN>>Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.

ГВ>Ну да, правильно. Так и должно быть.
А если именно это и нужно?

ГВ>>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.
AN>>А на что они еще влияют кроме последовательности сборки/компиляции?

ГВ>В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.
Никак не могу понять навар, кроме того, что бильд довольно часто был неправильным, приходилось все полностью перестраивать.

ГВ>>>Тогда, если нам понадобится убрать Lib, чтобы случайно не зацепить его исходники, мы можем просто удалить его из солюшена. Правда, при вставке обратно придётся заново проставить зависимости, поэтому лучше просто сделать новый солюшен — сами .csproj менять при этом не нужно.
AN>>Как то сложно представить удобство переключения солюшен,

ГВ>Alt-Tab
Несколько студий одновременно? Стараемся избегать...

AN>>да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?

ГВ>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.

ГВ>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.

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

ГВ>>>>Ясно. Нет, я немножко про другое говорю.
ГВ>>>>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.
ГВ>>>>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
AN>>>Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.
ГВ>>Ну да, правильно. Так и должно быть.
AN>А если именно это и нужно?

Как раз для того, чтобы можно было пересобрать проекты полностью и делается "большой" солюшен, куда включено всё необходимое.

ГВ>>>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.
AN>>>А на что они еще влияют кроме последовательности сборки/компиляции?
ГВ>>В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.
AN>Никак не могу понять навар, кроме того, что бильд довольно часто был неправильным, приходилось все полностью перестраивать.

Ну вам же надо защитить исходники от случайного редактирования?

ГВ>>>>Тогда, если нам понадобится убрать Lib, чтобы случайно не зацепить его исходники, мы можем просто удалить его из солюшена. Правда, при вставке обратно придётся заново проставить зависимости, поэтому лучше просто сделать новый солюшен — сами .csproj менять при этом не нужно.
AN>>>Как то сложно представить удобство переключения солюшен,
ГВ>>Alt-Tab
AN>Несколько студий одновременно? Стараемся избегать...

У-у-у, как всё запущено...

AN>>>да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?
ГВ>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
ГВ>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
AN>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.

Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.

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

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

ГВ>>>>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.
AN>>>>А на что они еще влияют кроме последовательности сборки/компиляции?
ГВ>>>В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.
AN>>Никак не могу понять навар, кроме того, что бильд довольно часто был неправильным, приходилось все полностью перестраивать.

ГВ>Ну вам же надо защитить исходники от случайного редактирования?
А..., если только для этого. А какой критерий переключения между солюшинами?

ГВ>>>>>Тогда, если нам понадобится убрать Lib, чтобы случайно не зацепить его исходники, мы можем просто удалить его из солюшена. Правда, при вставке обратно придётся заново проставить зависимости, поэтому лучше просто сделать новый солюшен — сами .csproj менять при этом не нужно.
AN>>>>Как то сложно представить удобство переключения солюшен,
ГВ>>>Alt-Tab
AN>>Несколько студий одновременно? Стараемся избегать...

ГВ>У-у-у, как всё запущено...
Как говорится, были преценденты.

AN>>>>да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?
ГВ>>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
ГВ>>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
AN>>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.

ГВ>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
А как "запретить" пользоваться этим солюшин для обычной работы

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

ГВ>>Ну вам же надо защитить исходники от случайного редактирования?
AN>А..., если только для этого. А какой критерий переключения между солюшинами?

Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься. Не знаю, я просто не вижу смысла работать с большим солюшеном, когда можно ограничиться маленьким — хотя бы из-за того, что упрощается навигация по дереву проектов. Ну и интеллисенс чуть пошустрей (если я его вообще не отрубаю, болтуна разэдакого).

AN>>>Несколько студий одновременно? Стараемся избегать...
ГВ>>У-у-у, как всё запущено...
AN>Как говорится, были преценденты.

И в чём же они выражались?

AN>>>>>да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?
ГВ>>>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
ГВ>>>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
AN>>>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.
ГВ>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
AN>А как "запретить" пользоваться этим солюшин для обычной работы

Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.

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

AN>>>Аргументируют, что Длл-ку имеет право изменить только "автор".

Z>>Это проблема. А если автор в командировке или на больничном?
A_A>У нас командная разработка или как?
A_A>Команда у нас коммуникативная?
A_A>В чем проблема?

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

Thread.Sleep(Randon.Next(3*1000*60*60*24));
Console.WriteLine("Dude, run msbuild now. Copy output to ....")

Уверен, что после третьего запуска вы затоскуете и подумаете об оптимизации процесса.

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

Z>>Эта проблема рождена нездоровой практикой иметь локальную версию и конечную (что бы не означали эти термины).
AN>Как сделать без локальной версии?
AN>Загрузился набор Длл-ок теперь требуется делать исправление в одной из них.

Я русским языком написал как. Надо подключать те dll которые получаются в процессе сборки исходников. Исключение — внешние, по отношению к проекту, библиотеки. Для них лучше использовать NuGet.

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

AN>>>>Аргументируют, что Длл-ку имеет право изменить только "автор".

Z>>>Это проблема. А если автор в командировке или на больничном?
A_A>>У нас командная разработка или как?
A_A>>Команда у нас коммуникативная?
A_A>>В чем проблема?

Z>Проблема в том, что вы предлагаете кроме разработки заниматься не пойми чем. Типа ждать пока коллега даст добро и выкладывать сборки. Попробуйте сами Z>позаниматься подобной работой. Вместо коллеги лучше написать программу.
Честно, не понял выделенного.
Коллега — это "автор" Длл-ки, который уехал в командировку?
Даст добро — т.е. у каждого члена проектной команды своя личная ответственность за набор функциональности и никто не имеет права менять эту
"чужую" функциональность без согласия ответственного?
Ждет заместитель коллеги или клиент, нуждающийся в Длл-ке?

Z>

Z>Thread.Sleep(Randon.Next(3*1000*60*60*24));
Z>Console.WriteLine("Dude, run msbuild now. Copy output to ....")
Z>

Может я не понял шутку юмора, но мы msbuild юзаем только для модификаций .msbuild скриптов.
Ну, и любимый кейс:
Блин, какого фига на CI тесты падают, а локально работают?

Z>Уверен, что после третьего запуска вы затоскуете и подумаете об оптимизации процесса.
А что именно подлежит оптимизации?

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

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

A_A>>как я понял, этот таргет присутствует во всех файлах проектов.
A_A>>Зашили его в шаблоны, на которых создаете новые проекты?

Q>Да Не сам таргет, его импорт:
Q>

Q><Import Project="$(Build)NuGet.targets" />
Q>

Выходит, во время каждого локального билда в студии дергается апдейт NuGet и он проверяет каждый фид?

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

Z>>Проблема в том, что вы предлагаете кроме разработки заниматься не пойми чем. Типа ждать пока коллега даст добро и выкладывать сборки. Попробуйте сами Z>позаниматься подобной работой. Вместо коллеги лучше написать программу.

A_A>Честно, не понял выделенного.
A_A>Коллега — это "автор" Длл-ки, который уехал в командировку?
A_A>Даст добро — т.е. у каждого члена проектной команды своя личная ответственность за набор функциональности и никто не имеет права менять эту
A_A>"чужую" функциональность без согласия ответственного?
A_A>Ждет заместитель коллеги или клиент, нуждающийся в Длл-ке?

Это по вашему сценарию:
A_A>Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
A_A>Первый кто готов — говорит второму, что закончил и залился.
A_A>Второй отвественен за релиз новой версии для всех нуждающихся.

A_A>Может я не понял шутку юмора, но мы msbuild юзаем только для модификаций .msbuild скриптов.

Эта фраза говорит о вашей полной некомпетентности в вопросах сборки. Зачем лезть с безапелляционными заявлениями в темы о которых вы практически ничего не знаете?

A_A>Ну, и любимый кейс:

A_A>Блин, какого фига на CI тесты падают, а локально работают?

Видимо очень любимый, раз не желаете с ним расставаться.

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

A_A>Выходит, во время каждого локального билда в студии дергается апдейт NuGet и он проверяет каждый фид?

Апдейт работает инкрементально. Т.е. если пакет нужной версии уже выкачан в папку Packages, то NuGet даже в интернет не лезет.

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

AN>>>>Несколько студий одновременно? Стараемся избегать...
ГВ>>>У-у-у, как всё запущено...
AN>>Как говорится, были преценденты.

ГВ>И в чём же они выражались?

Я так чувствую, судя по проблемам с местом на диске для рабочих копий, многочасовым апдейтам, проблемам с запуском студии работают они на каком то фантастически дохлом железе.

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

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

ГВ>>>Ну вам же надо защитить исходники от случайного редактирования?
AN>>А..., если только для этого. А какой критерий переключения между солюшинами?

ГВ>Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься.
Ну так всегда и будешь работать с большим.
ГВ>Не знаю, я просто не вижу смысла работать с большим солюшеном, когда можно ограничиться маленьким — хотя бы из-за того, что упрощается навигация по дереву проектов.
Для этого есть папочки в солюшине.
ГВ>Ну и интеллисенс чуть пошустрей (если я его вообще не отрубаю, болтуна разэдакого).
Зависимость интеллисенса решарпера от количества проектов, пока не наблюдалась. Не ну есть там некоторые зависящие фишки. А вот от размера рабочего файла зависит существенно.

AN>>>>Несколько студий одновременно? Стараемся избегать...
ГВ>>>У-у-у, как всё запущено...
AN>>Как говорится, были преценденты.

ГВ>И в чём же они выражались?
Точно уже не помню, давно было. Плагины выбрыкивались, нужно помнить в каком порядке их закрывать что бы на следущий день нужный проект открылся. Не все обновления происходят, ну в одном проекте закоммитили данные, а во втором так и осталось. Изменения проекта в одном иногда могли приводить к затыку в другой.

AN>>>>>>да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?
ГВ>>>>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
ГВ>>>>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
AN>>>>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.
ГВ>>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
AN>>А как "запретить" пользоваться этим солюшин для обычной работы

ГВ>Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.

Так дело то не в руках. За всеми вариантами просто можно не уследить.

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

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

Z>>>Эта проблема рождена нездоровой практикой иметь локальную версию и конечную (что бы не означали эти термины).
AN>>Как сделать без локальной версии?
AN>>Загрузился набор Длл-ок теперь требуется делать исправление в одной из них.

Z>Я русским языком написал как. Надо подключать те dll которые получаются в процессе сборки исходников.
Так это и сеть локальная версия Длл-ки.
Z>Исключение — внешние, по отношению к проекту, библиотеки. Для них лучше использовать NuGet.
Внешние, можно сказать не меняются.

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

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

A_A>>Выходит, во время каждого локального билда в студии дергается апдейт NuGet и он проверяет каждый фид?

Q>Апдейт работает инкрементально. Т.е. если пакет нужной версии уже выкачан в папку Packages, то NuGet даже в интернет не лезет.

Удобно
Предполагаю, что время дерганья NuGet, пусть даже и вхолостую, весьма ничтожно.
Надо буит нашим билд инженерам(они за NuGet отвечают) скзать, чтоб также прикрутили.

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

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

Z>>>Проблема в том, что вы предлагаете кроме разработки заниматься не пойми чем. Типа ждать пока коллега даст добро и выкладывать сборки. Попробуйте сами Z>позаниматься подобной работой. Вместо коллеги лучше написать программу.

A_A>>Честно, не понял выделенного.
A_A>>Коллега — это "автор" Длл-ки, который уехал в командировку?
A_A>>Даст добро — т.е. у каждого члена проектной команды своя личная ответственность за набор функциональности и никто не имеет права менять эту
A_A>>"чужую" функциональность без согласия ответственного?
A_A>>Ждет заместитель коллеги или клиент, нуждающийся в Длл-ке?

Z>Это по вашему сценарию:
A_A>>Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
A_A>>Первый кто готов — говорит второму, что закончил и залился.
A_A>>Второй отвественен за релиз новой версии для всех нуждающихся.
Дык, я и не отрицаю-то
Кто ждет-то и чего ждет, лучше объясните.

A_A>>Может я не понял шутку юмора, но мы msbuild юзаем только для модификаций .msbuild скриптов.

Z>Эта фраза говорит о вашей полной некомпетентности в вопросах сборки. Зачем лезть с безапелляционными заявлениями в темы о которых вы практически ничего не знаете?
"А судьи кто?" (С)
А можно по-конкретней?

A_A>>Ну, и любимый кейс:

A_A>>Блин, какого фига на CI тесты падают, а локально работают?

Z>Видимо очень любимый, раз не желаете с ним расставаться.
А Вы как с ним расстались?

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

ГВ>>>>Ну вам же надо защитить исходники от случайного редактирования?
AN>>>А..., если только для этого. А какой критерий переключения между солюшинами?
ГВ>>Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься.
AN>Ну так всегда и будешь работать с большим.

С чего бы это?

ГВ>>Не знаю, я просто не вижу смысла работать с большим солюшеном, когда можно ограничиться маленьким — хотя бы из-за того, что упрощается навигация по дереву проектов.
AN>Для этого есть папочки в солюшине.

Всё равно навигация усложняется. И потом, эти самые папки — они тоже "для всех", лишних для себя лично не понаделаешь.

AN>>>>>Несколько студий одновременно? Стараемся избегать...
ГВ>>>>У-у-у, как всё запущено...
AN>>>Как говорится, были преценденты.
ГВ>>И в чём же они выражались?
AN>Точно уже не помню, давно было. Плагины выбрыкивались, нужно помнить в каком порядке их закрывать что бы на следущий день нужный проект открылся.

Ну... Допустим. Правда, я бы, скорее, плагин снёс в таком случае.

AN>Не все обновления происходят, ну в одном проекте закоммитили данные, а во втором так и осталось.

Что осталось? И студия не сказала, что проект обновился?

AN>Изменения проекта в одном иногда могли приводить к затыку в другой.

Странно, а что вы за плагины используете?

ГВ>>>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
AN>>>А как "запретить" пользоваться этим солюшин для обычной работы
ГВ>>Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.

AN>Так дело то не в руках. За всеми вариантами просто можно не уследить.

Не понимаю. Если есть риск случайно поменять и закоммитить исходники из большого солюшена, пользуйся компактным солюшеном с небольшим количеством проектов. Если лениво переключаться — ССЗБ.

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

AVK>>А зачем всякую фигню на сотни мег класть рядом с исходниками?
A_A>Никакой фигни — куча сорцов, причем процентов 70 — легаси кода.

Папки на сотни мегабайт исходников легаси-кода? В воображении сразу рисуется что-то вроде хардкорного C и C++ имени VC6...

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

AN>>>Уже пару раз бывало, сижу пытаюсь понять/разобраться отчего какая-то операция на SVN не идет.
AVK>>Странно, почему у меня такого не бывает.
AN>Ты просто делаешь одно и тоже не выходя за рамки. Последнее, что я немного помню, переименовал файл в студии (причем забыл, что эта зараза не любит просто смену регистра) и все, затык — ни туда ни сюда.

Удалить-закоммитить-добавить-закоммитить. Проверено, помогает. Будет несколько сложнее восстановить историю изменений, но это, как правило, нужно крайне редко.

AN>>> Приходит админ, у него тоже нифига не получается. Ну и зачем еще время тратить, когда можно удалить и скачать по новому.
AVK>>Это, значит, админ так у вас рабочие копии сносит?
AN>Ну, не так грубо, вначале делается локальная копия. Потом восстанавливается работоспособность, а после исходники.

И для этого нужен аж целый админ??? Да у вас там синекура — админ папки разработчику чистит.

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

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

ГВ>>>>>Ну вам же надо защитить исходники от случайного редактирования?
AN>>>>А..., если только для этого. А какой критерий переключения между солюшинами?
ГВ>>>Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься.
AN>>Ну так всегда и будешь работать с большим.

ГВ>С чего бы это?
Сбилдил либу, отлаживаешь, исправляешь, билдишь. Когда переключаться и кто будет этим заниматься? Все лишние телодвижения.

ГВ>>>Не знаю, я просто не вижу смысла работать с большим солюшеном, когда можно ограничиться маленьким — хотя бы из-за того, что упрощается навигация по дереву проектов.
AN>>Для этого есть папочки в солюшине.

ГВ>Всё равно навигация усложняется. И потом, эти самые папки — они тоже "для всех", лишних для себя лично не понаделаешь.
Если солюшин "личная", то и папочки будут также личными. А отчего навигация усложняется? Вместо "отсутствующих проектов" будет просто одна папочка с именем, более того, обнаружив ее пустой можно четко сказать что это обкоцанная солюшин.

AN>>Не все обновления происходят, ну в одном проекте закоммитили данные, а во втором так и осталось.

ГВ>Что осталось? И студия не сказала, что проект обновился?
Речь о "соурсе контрол" прежде всего. В одном проекте исходники имеют статус "закоммитены", в другом нет.

AN>>Изменения проекта в одном иногда могли приводить к затыку в другой.

ГВ>Странно, а что вы за плагины используете?
Мы вообще больше грешили на студию.

ГВ>>>>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
AN>>>>А как "запретить" пользоваться этим солюшин для обычной работы
ГВ>>>Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.

AN>>Так дело то не в руках. За всеми вариантами просто можно не уследить.

ГВ>Не понимаю. Если есть риск случайно поменять и закоммитить исходники из большого солюшена, пользуйся компактным солюшеном с небольшим количеством проектов. Если лениво переключаться — ССЗБ.
Не сколько лениво, сколько неудобно. Сейчас просто нажимаешь ф5 и ждешь запуска проги. А тут получается нужно бильдить в одном, запускаться в другом, да и еще отключать нугет (которого впрочем пока и нет)
Да и при бильде все равно получаются "локальные Длл-ки", что вроде неприемлимо.