Чи потрібно чистити / відновлювати проект перед налагодженням / публікацією його у Visual Studio?

Це, мабуть, дурне питання, але чи потрібно чистити / відновлювати перед налагодженням чи публікацією проекту Visual Studio?

Я бачу, як інші розробники роблять це постійно, і в якийсь момент я почав це робити, навіть не замислюючись. Здається, звичка завжди йти чисто, чекати, перебудовувати, чекати, публікувати.

Я знаю, що я не завжди робив це .... Я думаю, що я почав це робити, витративши багато часу на налагодження помилки, лише щоб виявити, що вона пішла, коли я очистив і відновив рішення. У мене теж не раз виникала ця проблема, тому я знаю, що це була не разова річ, але, здається, це величезна витрата часу на те, щоб завжди чистити / перебудовувати свої проекти.

Вам не доведеться , але я вважаю, що Visual Studio іноді втрачає сліди того, які збірки були побудовані коли. Коли це трапляється, у вас виникають несвіжі збори та поганий досвід налагодження (коли код та символи не збігаються).

Як результат, я просто щоразу переробляю (це робить Clean + Build). Таким чином, я не покладаюся на хіт і промах Visual Studio;)

Це не потрібно ", але ви можете зробити Clean + Build перед основним випуском та / або після отримання файлів з інших ресурсів.

VS іноді не вдається ідентифікувати модифіковані файли і, таким чином, обходить необхідну повторну компіляцію. У моєму випадку це зазвичай відбувається, коли файли оновлюються через деяку поведінку перезапису (наприклад, завантаження з SCM, копіювання / вставка з каталогу колеги). Можливо, проблема - це дата файлу. Якщо новий файл має змінену дату (або створену дату, я не знаю, на яку посилання VC посилається), старішу, ніж у записі VS, VS не перекомпілює відповідний файл.

Моя рекомендація: якщо ви збираєте оновлення, зроблені лише вами локально на одній машині, ви маєте бути добре, будуючи без очищення.

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

У нашому магазині ми робимо це так само, але я впевнений, що відновлення також спрацювало б чудово.