Visual studio не меняется код
У меня очень странная ситуация, когда изменения, внесенные в репозиторий моими коллегами при обновлении моей локальной копии программного обеспечения, Visual Studio не сразу их распознает и перезагружает. результат (и это очень странно) заключается в том, что большую часть времени я сохраню свои изменения без перезагруженных проектов и перезапишу изменения моих коллег. Мне так стыдно, что меня иногда спрашивают, почему мне пришлось изменить код, и на самом деле я этого не делал. Другое дело, когда я проверяю некоторые изменения уровня проекта VS, например, когда кто-то добавляет новый класс или форму или что-то еще и продолжает работать в Visual Studio, мне потребуется не менее 5-10 минут, прежде чем я получу предупреждение о том, что были некоторые изменения и попросили перезагрузить проект и т.д….
Я думаю, что в visual studio должна быть настройка, чтобы запускать автоматическую перезагрузку, но не может ее найти. Это влияет на меня и на другого человека, но мой самый странный, так как это может занять до 30 минут до перезагрузки проекта.
Любые идеи приветствуются
Это мои настройки
Если вы работаете с Source Control, вам необходимо синхронизировать свою локальную рабочую область с сервером (“получить” последний код), прежде чем какие-либо изменения ваших коллег будут скопированы на ваш компьютер.
Если вы не “получите” последний код перед внесением изменений, возможно, вам придется объединить свои изменения с чужим, что может быть сложным, трудоемким или даже опасным процессом, особенно если вы используете автоматическое слияние Visual Studio по умолчанию процесс, который обычно делает неправильную вещь, приводящую к по существу коррумпированному коду (делая его похожим на то, что вы удалили работу своего коллеги, как вы описываете, например).
Лучший способ работать с контролем источника – это “маленький и часто” подход:
- Получите последний исходный код, прежде чем начинать новую работу, чтобы ваш компьютер был как можно более современным.
- Как правило, хорошая практика часто “получать” последний код (например, я делаю это сначала каждое утро), чтобы любые конфликты слияния были отмечены и рассмотрены как можно раньше. Чем дольше вы ждёте до слияния, тем хуже происходит процесс слияния. (Caveat: проверьте с вашей системой сборки, что текущая версия кода на сервере работает до того, как вы ее получите, – вы не хотите, чтобы на вашем ПК был поврежден код, так как это может помешать вам вообще работать).
- Устройте свою работу как можно больше небольших шагов, которые можно безопасно проверять по мере их завершения (вместо того, чтобы работать в течение 3 месяцев сотнями файлов, а затем сбрасывать их в систему как одно массовое изменение)
- Когда вы будете готовы к регистрации, получите последний код, перестройте и повторно проверьте свои изменения, чтобы убедиться, что они все еще работают, когда они интегрированы с последним программным кодом. Только проверьте, все ли работает хорошо.
Также имейте в виду, что когда вы пытаетесь отредактировать файл, поставщик управления источником может автоматически “получить” последнюю версию этого файла для вас (что может заставить Visual Studio сказать вам, что оно перезагрузило файл и, возможно, объяснит, почему вы говорите иногда требуется некоторое время, чтобы “обновить”, поскольку это происходит не до тех пор, пока вы не начнете редактировать новый файл, который недавно был изменен кем-то другим). Если это так, то правда заключается в том, что вы не “обновили” весь набор исходных кодов, а только один файл – в этом случае вам действительно нужно получить все последние изменения в исходном коде (если вы этого не сделаете вы можете обнаружить, что он несовместим или (что еще хуже) компилирует, но демонстрирует неопределенное поведение из-за того, что только часть обновляемого кода)
Наконец, очень хорошая практика при проверке кода состоит в том, чтобы просмотреть список файлов, которые вы проверяете, и разделить их по одному на последний код сервера, чтобы узнать, что вы изменили. Это может показаться трудоемким, но оно дает несколько преимуществ:
Заключительное примечание. Параметры, отображаемые в вашем редактировании, относятся только к изменениям, внесенным в файлы на вашем компьютере, с помощью другой программы на вашем ПК. Если другой пользователь вносит изменения и проверяет его на источник, эти параметры не будут иметь никакого эффекта. Только когда ваша система управления версиями копирует эти изменения на жесткий диск вашего ПК, вы можете увидеть, что Visual Studio реагирует на эти изменения (в зависимости от того, насколько хорошо ваша система управления версиями интегрирована с VS).
Если вы уверены, что проблема связана с Visual Studio (например, файл действительно изменился на диске, но вы не видите его в Visual Studio)
Убедитесь, что установлен параметр ” Detect when file is changed .
Tools > Options > Environment > Documents > Detect when file is changed outside the environment
Так как вы иногда получаете предупреждение для перезагрузки проекта из-за внешних изменений, значит, у вас уже есть настройки, необходимые для обнаружения изменений файлов в Visual Studio.
Однако перезагрузка проекта/решения будет инициирована только при изменении файлов.csproj (или.vbproj) или.sln.
Кстати, используете ли вы какую-то систему контроля версий? Кажется, что вы просто делитесь решением и редактируете одновременно.
я изменил его на:
Текст меняется в Visual Studio и .cs файле, но в самой программе не меняется. Меняется после перезагрузки ПК и еще одной компиляции. В чем проблема?
Уточните, где вы берете исполняемый файл "самой программы"? Вы точно его перекомпилировали? Есть подозрение, что по F5 происходит только перезапуск приложения из среды разработки, но не полноценное построение exe-файла для конечного пользователя. Особенно если приложение ставится через установщик (.msi или что там сейчас популярно).
@NickVolynkin, Открываю проект "launcher.sln", перехожу к файлу "Form1.cs", меняю тексты и нажимаю F5. F5 в Visual Studio означает Run, чуть правее выбрано "Release". Файл создается "\launcher\bin\x86\Release"
Ага, вот по такому описанию уже можно понять. Сожалею, у меня студии нет, но вообще тут шарпистов много, наверняка ответят )
пробовали делать rebuild перед запуском? Что говорит диспетчер задач - процесс вашего лаунчера не остается висеть в памяти после закрытия? Что студия пишет в логах компиляции? Очень похоже что исполняемый файл чем-то залочен (антивирусом?) и не может быть изменен в процессе компиляции.
@rdorn, rebuild не пробовал. Процесс не висит. При компиляции пишет, что загружает какие-то библиотеки. позже запускает программу. Ошибок и предупреждений нет. Не знаю как, но проблема решилась сама. Сейчас после каждой модификации текста он меняются и в программе
1 ответ 1
Возможно проблема в одной из особенностей студии, уж не знаю, баг это или фича, но некоторое количество моих нервов она в свое время мне попортила.
Случай первый:
Действия пользователя:
Через меню открыть->проект или кликом по файлу otherProject.sln в папке открываем любой другой проект.
Реакция студии:
Проект открывается в новом экземпляре студии, все хорошо, поведение при компиляции и запуске ожидаемое.
Случай второй:
Действия пользователя:
Через меню открыть->файл или кликом по файлу в папке открываем someFile.cs .
Реакция студии:
Файл открывается в новой вкладке редактора, не зависимо, принадлежит ли файл уже открытому проекту или нет. И это иногда бывает плохо.
Можно, например, открыть файл, имя которого совпадает с одним из файлов открытого проекта или открыть файл из копии проекта. При этом визуально этот, чужой для проекта, файл ни как не отличается и наличие либо отсутствие в нем ошибок не влияет ни на процесс компиляции, т.к. он в нем не участвует, ни на результат компиляции, по той же причине. Простой способ вычислить двойника, это закрыть все вкладки вообще и открыть нужные через Обозреватель решений .
Вообще студия не очень умеет работать с одиночными файлами, я бы сказал, вообще не умеет, только с проектами и всеми сопутствующими атрибутами. Поэтому после открытия проекта, я категорически рекомендую пользоваться исключительно Обозревателем решений для открытия файлов с исходным кодом.
Visual Studio включает эффективный интегрированный набор средств сборки и отладки проектов. Из этой статьи вы узнаете, как Visual Studio может помочь обнаружить проблемы в коде с помощью построения выходных данных, анализа кода, средств отладки и модульных тестов.
Мы разобрались, как работать с редактором, и написали код. Теперь необходимо убедиться, что код работает должным образом. Отладка в Visual Studio, как и в большинстве интегрированных сред разработки (IDE), осуществляется в два этапа: построение кода для обнаружения и устранения ошибок проекта и компилятора и выполнение кода для обнаружения ошибок времени выполнения и динамических ошибок.
Сборка кода
Существует два основных типа конфигурации сборки: отладка и выпуск. При использовании конфигурации отладка создается более крупный и медленный исполняемый файл, обеспечивающий более широкие интерактивные возможности отладки во время выполнения. Исполняемый файл конфигурации отладка никогда не следует отправлять. Конфигурация выпуск позволяет создать более быстрый оптимизированный исполняемый файл, подходящий для отправки (по крайней мере с точки зрения компилятора). По умолчанию используется конфигурация Отладка.
Самый простой способ выполнить сборку проекта — нажать клавишу F7, однако вы также можете начать сборку, выбрав в главном меню пункты Сборка > Собрать решение.
Процесс сборки можно наблюдать в окне Вывод в нижней части пользовательского интерфейса Visual Studio. Здесь отображаются ошибки, предупреждения и операции сборки. При наличии ошибок (или предупреждений выше заданного уровня) сборка завершится ошибкой. Можно щелкнуть ошибку и предупреждение, чтобы перейти к строке, где они возникли. Для перестроения проекта можно нажать клавишу F7 (чтобы перекомпилировать только файлы с ошибками) или CTRL+ALT+F7 (для чистого полного перестроения).
После успешного выполнения построения вы увидите примерно следующие результаты в окне Вывод:
Просмотр списка ошибок
Если вы внесли какие-либо изменения в код, который был ранее и успешно скомпилирован, возможно, возникнет ошибка. Если вы новичок в написании кода, возможно, их будет много. Ошибки иногда очевидны, например простая синтаксическая ошибка или неправильное имя переменной, а иногда их причину трудно выяснить, имея в распоряжении только зашифрованный код. Чтобы получить более четкое представление о проблеме, перейдите вниз окна Вывод сборки и щелкните вкладку Список ошибок. При этом вы перейдете к более организованному представлению ошибок и предупреждений для проекта и получите доступ к некоторым дополнительным параметрам.
Щелкните строку ошибки в окне Список ошибок, чтобы перейти в строку кода, в которой возникла ошибка. (Кроме того, номера строк можно включить, нажав клавиши Ctrl+Q, введя номера строк, а затем выбрав Включить или отключить отображение номеров строк в результатах. Это самый быстрый способ перехода в диалоговое окно Параметры, где можно включить номера строк.
Нажмите клавиши CTRL+G для быстрого перехода к номеру строки, в которой возникла ошибка.
Ошибку можно узнать по подчеркиванию красной волнистой линией Чтобы получить дополнительные сведения, наведите на нее указатель мыши. Внесите исправления, и подчеркивание исчезнет, хотя в результате исправления может возникнуть новая ошибка (это называется "регрессия").
Пройдите список ошибок и устраните все ошибки в коде.
Просмотр подробных сведений об ошибках
Многие ошибки трудны для восприятия, будучи представленными в терминах компилятора. В этом случае могут потребоваться дополнительные сведения. Из окна Список ошибок можно выполнить автоматический поиск в поисковой системе Bing для получения дополнительных сведений об ошибке или предупреждении. Щелкните правой кнопкой мыши по соответствующей строке записи и выберите Показать справочные сведения об ошибке из контекстного меню или щелкните гиперссылку с кодом ошибки в столбце код в списке ошибок.
В зависимости от настроек результаты поиска по коду и описанию ошибки откроются в веб-браузере либо во вкладке Visual Studio с результатами поиска Bing. Представленные результаты — из различных источников в Интернете, и, возможно, не все они будут полезными.
Анализ кода
Средства анализа выполняют поиск общих проблем в коде, которые могут привести к ошибкам времени выполнения или проблемам управления кодом.
Анализ кода C++
Чтобы выполнить анализ кода C++, запустите статический анализ кода. Запустить этот компонент после устранения всех очевидных ошибок, препятствующих успешной сборке, и потратить некоторое время, чтобы устранить создаваемые им предупреждения, — очень полезная привычка. Вы сможете избавиться от определенных будущих проблем, а также научитесь некоторым полезным приемам написания кода.
Нажмите клавиши ALT+F11 (или выберите в верхнем меню команду Анализ > Выполнить анализ кода в решении) для запуска статического анализа кода.
Все новые или обновленные предупреждения отображаются на вкладке Список ошибок в нижней части интегрированной среды разработки. Щелкните предупреждение для перехода к нему в коде.
Использование быстрых действий для исправления или рефакторинга кода
Если вы привыкли работать с клавиатурой, вы можете использовать клавиши со стрелками и сочетание клавиш CTRL+ . для проверки возможностей оптимизации и очистки кода!
Запуск очистки кода
Помимо форматирования пробелов, отступов и т. п., функция Очистка кода применяет определенные вами соглашения о стиле кода. Ваши настройки для каждого стиля кода считываются из файла EditorConfig, если такой существует в проекте, или из раздела Параметры стиля кода, который доступен через диалоговое окно Параметры.
Отладка выполняемого кода
Успешно завершив сборку кода и его очистку, запустите код, нажав клавишу F5 или выбрав команду Отладка > Начать отладку. Приложение будет запущено в среде отладки, и вы сможете пронаблюдать его поведение. Интегрированная среда разработки Visual Studio изменяется во время выполнения приложения: окно Вывод заменяется двумя новыми окнами (в конфигурации окон по умолчанию): окном с вкладками Видимые/Локальные/Контрольные значения и окном с вкладками Стек вызовов/Точки останова/Параметры исключений/Вывод. Эти окна имеют несколько вкладок, которые позволяют просмотреть и проверить переменные, потоки, стеки вызовов приложения и другие характеристики поведения во время выполнения приложения.
Остановите приложение, нажав клавиши SHIFT+F5 или кнопку Остановить. Кроме того, можно просто закрыть главное окно приложения (или диалоговое окно командной строки).
Задание простых точек останова
Точки останова — это один из самых простых и важных компонентов надежной отладки. Точка останова указывает, где Visual Studio следует приостановить выполнение кода, чтобы вы могли проверить значения переменных или поведение памяти либо выполнение ветви кода. После установки или удаления точек останова перестраивать проект не нужно.
Установите точку останова, щелкнув дальнее поле строки, в которой требуется приостановить выполнение, или нажмите клавишу F9, чтобы установить точку останова в текущей строке кода. Выполнение кода прерывается (останавливается) перед инструкциями для этой строки кода.
Чаще всего точки останова используются для решения следующих задач.
Чтобы точнее определить источник аварийного завершения или отсутствия отклика программы, расставьте точки останова вокруг и непосредственно в коде вызова метода, который, по вашему мнению, приводит к сбою. При выполнении кода в отладчике удаляйте, а затем снова устанавливайте точки останова ближе друг к другу, пока не найдете строку кода, вызывающую ошибку. Выполнение кода в отладчике описывается в следующем разделе.
При добавлении нового кода установите точку останова в его начале и выполните код, чтобы убедиться в том, что он работает правильно.
При реализации сложного поведения задайте точки останова для алгоритмического кода, чтобы можно было проверить значения переменных и данные при прерывании программы.
При написании кода C или C++ используйте точки останова для остановки кода, чтобы можно было проверить значения адреса (ищите значение NULL) и просмотреть значения счетчиков при отладке ошибок, связанных с памятью.
Дополнительные сведения о точках останова см. в статье Использование точек останова.
Проверка кода во время выполнения
Когда выполнение кода приостанавливается из-за достижения точки останова, строка кода, помеченная желтым цветом (текущий оператор), еще не выполнена. Вы можете выполнить текущий оператор и проверить, как изменились значения. Для выполнения кода в отладчике можно использовать ряд команд пошагового выполнения. Если отмеченный код является вызовом метода, вы можете выполнить шаг с заходом, нажав клавишу F11. Кроме того, можно выполнить шаг с обходом строки кода, нажав клавишу F10. Дополнительные команды и подробные сведения о пошаговом выполнении кода см. в статье Навигация по коду с помощью отладчика.
Код, представленный на предыдущей иллюстрации, может выполняться отладчиком по одному оператору. Для этого можно нажимать клавишу F10 или F11 (так как здесь нет вызова метода, результат выполнения обеих команд будет одинаковым).
Когда отладчик приостанавливает выполнение, можно проверить переменные и стеки вызовов, чтобы разобраться в происходящем. Находятся ли значения в тех диапазонах, которые вы ожидали увидеть? Выполняются ли вызовы в правильном порядке?
Наведите курсор на переменную для просмотра ее текущего значения и ссылок. Если отображается значение, которое вы не ожидали увидеть, возможно, в предыдущем или вызывающем коде имеется ошибка. Более подробные сведения об отладке см. в статье об использовании отладчика.
Кроме того, Visual Studio выводит на экран окно средств диагностики, где можно наблюдать за загрузкой ЦП и использованием памяти приложением в динамике по времени. В дальнейшем в процессе разработки приложения эти средства можно применять для выявления случаев непредвиденно высокой загрузки ЦП или чрезмерного выделения памяти. Это окно можно использовать в сочетании с окном Контрольные значения и точками останова, чтобы определить причину непредвиденно интенсивного использования или неосвобожденных ресурсов. Дополнительные сведения см. в статье Обзор возможностей профилирования.
Запуск модульных тестов
Модульные тесты — это первая линия защиты от ошибок в коде, так как при правильном проведении они позволяют проверять отдельные "модули" кода (как правило, это отдельные функции), которые проще отлаживать, чем всю программу. Visual Studio устанавливает платформу модульного тестирования Майкрософт для управляемого и машинного кода. Платформа модульного тестирования используется для создания модульных тестов, их запуска и передачи результатов таких тестов. Завершив внесение изменений, запустите модульные тесты повторно, чтобы убедиться, что код по-прежнему работает правильно. При использовании выпуска Visual Studio Enterprise можно настроить автоматический запуск тестов после каждой сборки.
Чтобы приступить к работе с модульными тестами, ознакомьтесь со статьей Создание модульных тестов для кода с помощью IntelliTest.
Дополнительные сведения о модульных тестах в Visual Studio, а также о том, как они могут помочь в создании более качественного кода, см. в статье Основные сведения о модульных тестах.
В VS под x64 запускаю в режиме отладки код, все работает. до какого то определенного момента. Спустя некоторое количество запусков разного кода, при вводе очередного примера, почему то запускается предыдущий код а не текущий, при этом никаких исключений, ошибок, предупреждений не вылетает. Последующие попытки запустить любой код приводят к такому же результату.
Подскажите в чем проблема и как ее пофиксить?
- Вопрос задан более трёх лет назад
- 1683 просмотра
Простой 8 комментариев
res2001, Пробовал. Изменений нет. Ладно уже пересоздал проект, пока все в порядке. Мне бы понять причину этого.
evg_96, Чаще всего нечто похожее случается из-за инкрементной сборки, которая в VC включена по умолчанию.
Поэтому самый первый совет в этом случае - очистить результаты сборки и пересобрать с нуля.
Так же можно вручную удалить из каталога проекта все объектные и исполняемые файлы (да и вообще все лишнее). Для проекта VC достаточно файлов:
*.vcproj* и *.sln (они находятся в корневом каталоге проекта) и ваши исходники, конечно. Все остальное можно удалять - это файлы и каталоги полученные в результате сборки проекта и при следующей сборке они снова появятся.
Еще можно отменить саму инкрементную сборку в свойствах проекта: General->Enable managed incremental build. Это приведет к тому, что каждая сборка будет полностью пересобирать проект. Это увеличит время сборки, но для учебных проектов время сборки обычно не критичный параметр.
В вашем случае не совсем понятно что именно привело к такому поведению. Думаю для вас оптимальным вариантом на данном этапе будет отключение инкрементной сборки.
Программа запущенная на прошлом этапе скорее всего повисла.
При пересборке компилятор не смог удалить предыдущий exe файл, так как программа еще висит.
Горячая перезагрузка позволяет вносить изменения в исходный код приложения во время его выполнения без необходимости приостанавливать его вручную или создавать точку останова. Теперь прямо во время работы приложения можно внести в код изменение из числа тех, что поддерживаются для горячей перезагрузки, нажать кнопку «Применить изменения кода» в новом интерфейсе Visual Studio — и изменение будет сразу же применено.
Мы стремились сделать горячую перезагрузку доступной независимо от того, как вы предпочитаете запускать свои приложения. Представленную сегодня версию можно использовать в отладчике Visual Studio, с которым она полностью интегрирована, а также через командную строку ( dotnet watch ). В следующих выпусках появятся и другие варианты.
Начало работы
Visual Studio
Использование горячей перезагрузки в Visual Studio при работе с отладчиком:
Скачайте и установите Visual Studio 2019 16.11 (предварительная версия 1).
Откройте проект поддерживаемого типа, например приложение WPF.
Запустите приложение с подключенным отладчиком клавишей F5 (удостоверьтесь, что параметр «Разрешить отладку машинного кода» в настройках/профиле запуска отладчика отключен).
Примените изменения кода с помощью новой кнопки Применить изменения кода (ALT + F10) на панели инструментов Visual Studio (рядом с кнопкой Продолжить). Сохранять файлы при использовании Visual Studio не нужно — можно быстро внести в код изменение и двигаться дальше.
Если внесенное изменение поддерживается, обновленная логика будет применена к запущенному приложению, и вы увидите изменения в его работе при следующем выполнении обновленного кода (по действию или при выполнении активирующего условия, например по таймеру).
Интерфейс командной строки (CLI)
Использование горячей перезагрузки из командной строки при запуске приложения с помощью dotnet watch:
Добавьте свойство " hotReloadProfile ": " aspnetcore " в профиль запуска приложения ( launchSettings.json ).
Пример файла Properties/launchSettings.json :
Запустите проект с помощью команды dotnet watch и убедитесь, что в выводе указано, что горячая перезагрузка активирована.
Внесите в управляемый исходный код приложения поддерживаемое изменение и сохраните файл, чтобы применить это изменение.
Как и в Visual Studio, с этого момента начнет применяться новая логика: при следующем выполнении обновленного кода вы увидите изменения в работе приложения.
Этот же подход можно использовать с проектами Blazor WebAssembly: следует изменить профиль горячей перезагрузки blazorwasm и далее действовать, как описано выше. Можно попробовать его даже с Windows Forms и другими типами проектов на платформе CoreCLR: для этого вручную добавьте в папку Properties файл с именем launchSettings.json и тем же содержимым, что в предыдущем примере.
Примеры ниже позволяют составить представление о том, какие возможности мы планируем реализовать в будущих предварительных выпусках и окончательной версии:
Работа в Visual Studio без отладчика. В будущем выпуске Visual Studio 2022 мы планируем добавить поддержку горячей перезагрузки без отладчика. Это значит, что даже при запуске приложения сочетанием клавиш CTRL + F5 разработчики смогут вносить изменения в выполняемое приложение.
Таковы планы на данный момент. Они не окончательные: мы будем прислушиваться к отзывам пользователей и ориентироваться на график выпусков.
Поддерживаемые и неподдерживаемые изменения и языки
Нам важны ваши отзывы
Конечно, в этой ранней предварительной версии будут ошибки. Иногда при попытке применить изменение ничего не будет происходить, иногда возможно аварийное завершение приложения и т. п. Если вы столкнетесь с какими-либо проблемами, сообщите нам о них — это не займет много времени. Ваша поддержка поможет нам эффективно устранить критические проблемы и определить приоритеты для дальнейшей работы.
Также приглашаем всех желающих на открытый урок «Управление конфигурациями микросервисов». На занятии обсудим один из подходов, используемых в реальных high-load проектах.
Читайте также: