«Точка розриву наразі не буде потраплена. Вихідний код відрізняється від оригінальної версії ». Що це означає?

Під час налагодження у Visual Studio іноді я додаю точку розриву, але вона порожня, і В.С. каже: "Точка зламу в даний момент не буде потрапляти. Вихідний код відрізняється від оригінальної версії". Очевидно, це заважає мені налагоджувати.

Що на землі означає повідомлення? Яка оригінальна версія? Якщо я щойно відкрив рішення та не вніс жодних змін у код, як може бути "оригінальна версія"?

Як мовиться, "вихідний код відрізняється від оригінальної версії".

Клацніть правою кнопкою миші на папці проекту у провіднику рішень та виберіть Clean. Побудуйте нову версію проекту, і точка розриву запрацює знову!

Якщо ви скасували проект DLL у конфігурації збірки налагодження , ваш новий код ніколи не буде побудований!

Перейдіть до Build --> Configuration Manager ...(у VS2010) і перевірте, чи проект з кодом, який ви намагаєтесь налагодити, перевіряється на поточну конфігурацію збірки.

Для мене це було під час роботи над проектом WebSite. Після очищення цих папок temp я повернув належні помилки компілятора:

• C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
• C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Нарешті я вирішив проблему, коли виявив, що файл класу, який я навмисно перемістив у підпапку, якимось чином з’явився у кореневій папці. VS використовував це одне, поки я редагував інший.

Ви коли-небудь це робили?

Ви хочете продовжити та запустити останню вдалу збірку?

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

Спробуйте змінити це значення:

• Інструменти
  • Параметри
    • Проекти та рішення
      • Побудувати та запустити
        • Під час запуску, коли виникають помилки побудови чи розгортання: Не запускати

Йти до

• Інструменти
  • Параметри
    • Налагодження
      • Загальні

Зніміть прапорець Потрібно, щоб вихідні файли точно відповідали оригінальній версії

Виберіть « Налагодження» в « Конфігурації рішення» , а не « Випуск»

Зверніть увагу на вікно "Вихід" у VS. Він підкаже, які збірки завантажуються і коли. Можливо, ви побачите, що десь у папці завантажується старіша версія вашої збірки.

Наприклад, якщо у вас є декілька збірок, і ви зараз намагаєтесь перерватися на одну з опорних зборів, CLR буде обробляти рішення монтажу, яке може завантажити інший файл збірки, ніж той, на який ви посилаєтеся в проекті.

Закриття Visual Studio і повторне відкриття рішення можуть усунути проблему, тобто помилка в самому IDE (я запускаю VS2010).

Якщо у вас є кілька екземплярів запущеного Visual Studio, вам потрібно лише закрити екземпляр, що виконує вирішення проблеми.

Новий спосіб вирішити цю проблему з'явився у Visual Studio 2017 15.3.1 до 15.3.5. Якщо ви використовуєте EditorConfig , цей charset=utf8параметр викликає ці симптоми. Команда VS відтворила це і каже, що над цим працюють .

Отже, одне виправлення - прокоментувати свій charset=utf8рядок у файлі .editorconfig.

Редагувати: це слід виправити станом на VS 15.5.

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

Для мене жоден із пунктів не вирішив питання. Я щойно додав новий рядок коду всередині цієї функції:

int a=0;

додавши це, я думаю, я запустив візуальну студію, щоб додати цю функцію до оригінальної версії

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

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

• Провідник рішень
  • клацніть правою кнопкою миші Рішення
    • Властивості
      • Загальні властивості
        • Налагодження вихідних файлів
          • Msgstr "Не шукайте ці вихідні файли".

Чомусь невідома мені причина, VS 2013 вирішив розмістити там вихідний файл, і згодом я більше не міг потрапити у цей файл. Це може бути винуватцем "вихідний код відрізняється від вихідної версії".

Проблема полягає в тому, що інформація про налагодження не синхронізується з вашою збіркою. Рішення просте:

1. Перейдіть до своєї папки
2. Видаліть .pdb файли
3. Перебудувати

Слід зробити трюк!

(дивна річ: відновлення без викидання .pdb файлів не завжди працює. Я бачу, що модифікована дата оновлюється, але все ще десь у ланцюзі (налагоджувач VS2013, IIS, кеш-збірка) ця зміна не виявлена )

Це повідомлення можна отримати, коли ви використовуєте активатор, і збірка, на яку встановлено точку розриву, ще не завантажена.

Точка розриву вирішиться, як тільки активатор завантажить збірку (якщо припустимо, що символи складання та налагодження оновлені). Хорошим місцем для перегляду є вікно модулів у меню налагодження. Там ви повинні шукати збірку, до якої також належить ваш файл. Спочатку перевірте, що збірка завантажена. Тоді звідки він завантажений? Потім завантажується файл символів. Знову ж, звідки завантажений файл символів? Нарешті перевірте версії обох.

Я також стикався з цим. Умови, які спричинили мою проблему:

• Я локально запускаю повний екземпляр IIS7
• Я перетворюю програмне забезпечення на окремі проекти

Я викликав це, відкривши попередню версію (VS запропонував запитати, чи хочу я вказати на цей екземпляр у налагодженні IIS, я відповів "Так"), а потім відкрив поточну версію (знову відповідаючи на запит IIS "Так" ), потім спробу налагодити в попередній версії.

Щоб вирішити, я просто закрив і повторно відкрив попередню і передбачувану версію, вкотре затвердивши її як джерело налагодження.

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

Це трапляється також при налагодженні проекту C ++, який завантажує модуль, реалізований з якоюсь мовою CRL (керований C ++, C # тощо). У цій ситуації повідомлення про помилку дійсно вводить в оману.

Рішення полягає в тому, щоб застосувати властивість конфігурації підтримки загальної мови (CLR) до проекту запуску і перекомпілювати це.

Якщо у вашому рішенні є кілька проектів , переконайтеся, що правильний проект встановлений як StartUp Project. Щоб встановити конкретний проект як проект запуску вашого рішення, клацніть правою кнопкою миші проект, виберітьSet As StartUp Project .

Після того, як я правильно встановив проект StartUp Project, потрібна точка розриву була досягнута потоком.

Я пережив це в 32-бітній версії vs2017.

Точно жодне з рішень не працювало для мене. Я перезапустив, я очистив файли IDE, очистив вбудований розчин, витягнув з git repo і відновив рішення безрезультатно.

Я витягував 64-бітову залежність від nuget, і як тільки я використовував збірку, джерела вже не вбудовувались у остаточний виконуваний файл, а замість цього створювались кешовані джерела IDE.

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

Це був біль, я сподіваюся, що він потрапляє до списку відповідей для всіх, хто бачить.

Редагувати: Під час збирання не було помилок, незважаючи на те, що в налаштуваннях IDE було включено опцію "підказка про помилку збірки".

Для мене рішення було приховано у Advanced Build Settingsвластивостях проекту:

З невідомої причини було встановлено наступне none: встановлення його для fullспричинення потрапляння точок прориву.

Щоб перейти до цього діалогового вікна, відкрийте властивості проекту, потім перейдіть до Build, а потім виберіть Advanced...кнопку внизу сторінки.

У мене був той самий випуск у кількох проектах у проекті багатошарової архітектури, і проблема полягала в конфігураціях, прапорець збірки для вибраного проекту не встановлено. тому питання було вирішено для одного проекту.

Для іншого шару він створював цю ж проблему, навіть увімкнення збірки у конфігураціях. Я зробив усі інші варіанти, такі як перезапуск очищення проекту, але не з них допомогло. Нарешті я зняв прапорець збірки для цього конкретного проекту та очистив та відновив. знову позначив прапорець і зробив те саме. тоді питання було вирішено.

Сподіваюся, це допомагає ..

У моєму випадку я приєднувався до запущеного процесу в VS 2012. Під час приєднання вам надається можливість налагодження в різних режимах (рідний, скрипт, сріблястий, керований 2.0, керований 4.0 тощо). За замовчуванням відладчик автоматично вибирає режим. Однак автоматичний не завжди робить правильний вибір. Якщо ваш процес містить кілька типів коду, переконайтеся, що налагоджувач використовує правильний.

У моєму випадку я розробляв додаток Windows CE, який перевірявся на емуляторі. Проблема полягала в тому, що виконуваний файл не було розгорнуто до емулятора, тому .pdb (у середовищі розробки) не синхронізувався з .exe (в емуляторі), оскільки новий .exe ніколи не копіювався в емулятор. Мені довелося видалити .exe в емуляторі, щоб примусити нове розгортання. Тоді це спрацювало.

Що для мене працювало - змінити платформу рішення з x86 на будь-який процесор. Після зміни на «Будь-який» я встановив адресу зупинки, запустив веб-сайт, відкрив сторінку, натиснув кнопку і вона зупинилася. Я закрив сайт, змінив назад на x86 і виконав ту саму послідовність успішно.

У Windows 7, Visual Studio Express 2010, якщо ви активували опцію Використовувати режим сумісності для Windows XP SP3 , ця помилка може статися.

Я скасував варіант, і він спрацював ідеально знову. Клацніть правою кнопкою миші по ярлику до VS або виконуваного файлу, виберіть властивості та сумісність .

Спочатку я спробував з командного рядка;

видалення тимчасових файлів із командного рядка спрацювало.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Тимчасові файли ASP.NET> root rd / s

Коли я відключаю опцію "Увімкнути лише мій код" в меню Інструменти -> Параметри -> Налагодження -> Загальне

Проблема вирішена для мене. Це програма WCF, намагалася налагодити сторінку ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

Це сталося зі мною, бо у мене були інші проекти, які не будували. Після того, як я вивантажив ці проблемні проекти (клацніть правою кнопкою миші на проект в Explorer Explorer -> Unload Project), відновив рішення і запустив знову - точка зламу потрапила!

Це трапилось у Visual Studio 2017 після того, як я додав існуючі файли до проекту. Це працювало для мене:

1. закрити рішення,
2. перейти до SolutionFolder\.vs\SolutionName\v15\sqlite3та видалитиstorage.ide
3. відкрити рішення знову

Переконайтесь, що ви не знаходитесь у режимі випуску, коли намагаєтесь налагоджувати.