2 Lloyd,
Я не понял...
Толи ты считаешь что иметь несколько солюшинов с ограниченным списком проектов для более комфортной работы плохо?
Толи ты всегда компилишь всю цепочку dependecies, даже если работа идет, допустим, уже как полгода только с одной сборкой? Даже если эта сборка unit-тесты и ничего более?
Или тебе никогда не приходилось ссылаться на бинарные сборки?
Или...

p/s/ то что должен существовать общий солюшин, который компилится по расписанию, например, ночью, никто не отрицает. Но работать в общем солюшине над одной сборкой, где ты меняешь порой пару строк — контрпродуктивно.

Здравствуйте, снежок, Вы писали:

С>p/s/ то что должен существовать общий солюшин, который компилится по расписанию, например, ночью, никто не отрицает. Но работать в общем солюшине над одной сборкой, где ты меняешь порой пару строк — контрпродуктивно.
С другой стороны, такой подход позволяет при рефакторинге легко сломать те сборки, которые от твоей текущей зависимы.

Mab>С другой стороны, такой подход позволяет при рефакторинге легко сломать те сборки, которые от твоей текущей зависимы.
рефакторим бинарные сборки через рефлектор

Здравствуйте, снежок, Вы писали:

С>рефакторим бинарные сборки через рефлектор
В смысле?

Mab>>С другой стороны, такой подход позволяет при рефакторинге легко сломать те сборки, которые от твоей текущей зависимы.
С>рефакторим бинарные сборки через рефлектор
это вопрос был

Здравствуйте, снежок, Вы писали:

С>это вопрос был
Пусть и вопрос, но какой-то он непонятный. При чем здесь рефлектор?

Mab>В смысле?
как сломать можно? проясни плиз.

Здравствуйте, снежок, Вы писали:

С>как сломать можно? проясни плиз.
Казалось бы очень просто: переименовываешь класс в сборке A, после чего сборка B, которая зависит от A и не была включена в solution, больше не компилируется.

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

C>Этот подход тоже имеет место быть!

C>2 Lloyd: За что минус человеку поставил? Попрошу обосновать!

Этот подход тоже имеет место быть только в одном случае — если хочешь огрести проблем.

Mab>Казалось бы очень просто: переименовываешь класс в сборке A, после чего сборка B, которая зависит от A и не была включена в solution, больше не компилируется.
А если б сборка [В] была в солюшине, то ничего не изменяя в ней она скомпилировалась бы?
...Просто, для отлова подобного, и существует компиляция "общего" солюшина, но запускаемая по расписанию. Ну и unit-тесты, соответственно.

p/s/ я не говорю что, ссылаться на бинарные сборки это the best, но в тоже время это может здорово экономить время разработчика.

Здравствуйте, снежок, Вы писали:
olution, больше не компилируется.
С>А если б сборка [В] была в солюшине, то ничего не изменяя в ней она скомпилировалась бы?
Если бы она была в солюшене, причем в исходниках, то рефакторинг был бы сквозным и отразился на ней.

С>...Просто, для отлова подобного, и существует компиляция "общего" солюшина, но запускаемая по расписанию. Ну и unit-тесты, соответственно.
Обнаруживать постфактум, что-то сломалось -- это здорово, но не то, чего бы хотелось. Фактически придется потом накатывать все рефакторинги руками.

С>p/s/ я не говорю что, ссылаться на бинарные сборки это the best, но в тоже время это может здорово экономить время разработчика.
Ну так и я не говорю, что это абсолютное зло. Возможный сценарий: есть большое ядро и множество зависимых только от него сборок-плагинов. При этом желательно, чтобы народ, работающий с плагинами, не мог менять ничего в ядре (по административным причинам). В этом случае можно выдать им ядро в бинарной форме.

С другой стороны, для подавляющего большинства случаев и вменяемой команде эта технология будет только мешать.

L>Этот подход тоже имеет место быть только в одном случае — если хочешь огрести проблем.
Проблем пока не встречалось , зато нервов сэкономлено много.
Сборок около сотни. Компиляция общего солюшина и прогон тестов по расписанию.

Здравствуйте, снежок, Вы писали:

С>p/s/ я не говорю что, ссылаться на бинарные сборки это the best, но в тоже время это может здорово экономить время разработчика.

На чем, если не секрет?

С>>А если б сборка [В] была в солюшине, то ничего не изменяя в ней она скомпилировалась бы?
Mab>Если бы она была в солюшене, причем в исходниках, то рефакторинг был бы сквозным и отразился на ней.
Угу в 2005 студии..., а в 2003 и 1.1?

Здравствуйте, снежок, Вы писали:
С>Угу в 2005 студии..., а в 2003 и 1.1?
Какая разница? Я Resharper имею в виду, а не встроенные средства.

L>На чем, если не секрет?
на времени компиляции. <see cref="сабж."/>

Здравствуйте, снежок, Вы писали:

L>>На чем, если не секрет?
С>на времени компиляции. <see cref="сабж."/>

Сколько ж она у вас занимает, что на ней можно здорово сэкономить?

L>Сколько ж она у вас занимает, что на ней можно здорово сэкономить?
посмеяться можно здесь

Здравствуйте, снежок, Вы писали:

L>>Сколько ж она у вас занимает, что на ней можно здорово сэкономить?
С>посмеяться можно здесь

Не ерничай. Просто ответь на вопрос.

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

Mab>Здравствуйте, снежок, Вы писали:
Mab>olution, больше не компилируется.
С>>А если б сборка [В] была в солюшине, то ничего не изменяя в ней она скомпилировалась бы?
Mab>Если бы она была в солюшене, причем в исходниках, то рефакторинг был бы сквозным и отразился на ней.
Далеко не все могут рефакторить весь слоюшен.