Нужно ли очищать / перестраивать проект перед его отладкой / публикацией в Visual Studio?

Вероятно, это глупый вопрос, но мне нужно очистить / перестроить перед отладкой или публикацией проекта Visual Studio?

Я вижу, что другие разработчики делают это все время, и в какой-то момент я начал делать это, даже не задумываясь. Кажется, привычка всегда идти Чисто, ждать, перестраивать, ждать, публиковать.

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

Вам не нужно , но я обнаружил, что Visual Studio иногда теряет отслеживание того, какие сборки были построены когда. Когда это происходит, вы получаете устаревшие сборки и плохую отладку (когда код и символы не совпадают).

В результате я просто делаю повторную сборку каждый раз (это делает Clean + Build). Таким образом, я не полагаюсь на хит и промах Visual Studio;)

Это не «обязательно», но вы можете выполнить Clean + Build перед основным выпуском и / или после получения файлов из других ресурсов.

Иногда VS не может определить измененные файлы и, таким образом, обходит необходимую перекомпиляцию. В моем случае это обычно происходит, когда файлы обновляются с помощью некоторого перезаписи (например, загрузка из SCM, копирование / вставка из каталога коллеги). Проблема, вероятно, в дате файла. Если новый файл имеет измененную дату (или дату создания, я не знаю, на какую временную метку ссылается VC) старше, чем в записи VS, VS не будет перекомпилировать соответствующий файл.

Моя рекомендация: если вы компилируете обновления, сделанные только вами локально на той же машине, у вас все будет в порядке, если вы собираете без очистки.

Очистка и восстановление - это просто простой способ очистки любых ошибочных сборок, ресурсов или других ресурсов, которые могли накопиться в предыдущих сборках. Это также помогает поддерживать сборки в согласованном состоянии, потому что Visual Studio иногда запутывается в том, что на самом деле ссылается.

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