Как вывести консоль в visual studio
Консольные приложения до сих пор остаются наиболее востребованным видом приложений, большинство разработчиков оттачивают архитектуру и бизнес-логику именно в консоли. При этом они нередко сталкиваются с проблемой локализации - русский текст, который вполне адекватно отражается в исходном файле, при выводе на консоль приобретает вид т.н. "кракозябр".
В целом, локализация консоли Windows при наличии соответствующего языкового пакета не представляется сложной. Тем не менее, полное и однозначное решение этой проблемы, в сущности, до сих пор не найдено. Причина этого, главным образом, кроется в самой природе консоли, которая, являясь компонентом системы, реализованным статическим классом System.Console, предоставляет свои методы приложению через системные программы-оболочки, такие как командная строка или командный процессор (cmd.exe), PowerShell, Terminal и другие.
По сути, консоль находится под двойным управлением - приложения и оболочки, что является потенциально конфликтной ситуацией, в первую очередь в части использования кодировок.
Данный материал не предлагает строгий алгоритм действий, а направлен на описание узловых проблем, с которыми неизбежно сталкивается разработчик локализованного консольного приложения, а также некоторые возможные пути их разрешения. Предполагается, что это позволит разработчику сформировать стратегию работы с локализованной консолью и эффективно реализовать существующие технические возможности, большая часть которых хорошо описана и здесь опущена.
Виды консолей
В общем случае функции консоли таковы:
управление операционной системой и системным окружением приложений на основе применения стандартных системных устройств ввода-вывода (экран и клавиатура), использования команд операционной системы и/или собственно консоли;
запуск приложений и обеспечение их доступа к стандартным потокам ввода-вывода системы, также с помощью стандартных системных устройств ввода-вывода.
Отдельным видом консоли можно считать консоль отладки Visual Studio (CMD-D ).
Конфликт кодировок
Полностью локализованная консоль в идеале должна поддерживать все мыслимые и немыслимые кодировки приложений, включая свои собственные команды и команды Windows, меняя "на лету" кодовые страницы потоков ввода и вывода. Задача нетривиальная, а иногда и невозможная - кодовые страницы DOS (CP437, CP866) плохо совмещаются с кодовыми страницами Windows и Unicode.
Совет 1. Выполнять разработку текстовых файлов (программных кодов, текстовых данных и др.) исключительно в кодировке UTF-8. Мир любит Юникод, а кроссплатформенность без него вообще невозможна.
Совет 2. Периодически проверять кодировку, например в текстовом редакторе Notepad++. Visual Studio может сбивать кодировку, особенно при редактировании за пределами VS.
Поскольку в консоли постоянно происходит передача управления от приложений к собственно командному процессору и обратно, регулярно возникает "конфликт кодировок", наглядно иллюстрируемый таблица 1 и 2, сформированных следующим образом:
Команды и код приложения под катом
> Echo ffffff фффффф // в командной строке
PS> Echo ffffff фффффф // в PowerShell
PS> Echo ffffff . // так выглядит та же команда в Windows PowerShell
код тестового приложения:
Командную часть задания все консоли локализовали практически без сбоев во всех кодировках, за исключением: в WPS неверно отображена русскоязычная часть команды во всех кодировках.
Табл. 1. Результат выполнения команды консоли Echo ffffff фффффф
Вывод тестового приложения локализован лишь в 50% испытаний, как показано в табл.2.
Табл. 2. Результат запуска приложения LoggingConsole.Test
Сoвет 3. Про PowerShell забываем раз и навсегда. Ну может не навсегда, а до следующей мажорной версии.
По умолчанию Windows устанавливает для консоли кодовые страницы DOS. Чаще всего CP437, иногда CP866. Актуальные версии командной строки cmd.exe способны локализовать приложения на основе русифицированной кодовой страницы 866, но не 437, отсюда и изначальный конфликт кодировок консоли и приложения. Поэтому
Совет 4. Перед запуском приложения необходимо проверить кодовую страницу консоли командой CHCP и ей же изменить кодировку на совместимую - 866, 1251, 65001.
Проблемы консолей Visual Studio
В Visual Studio имеется возможность подключения консолей, по умолчанию подключены командная строка для разработчика и Windows PowerShell для разработчика. К достоинствам можно отнести возможности определения собственных параметров консоли, отдельных от общесистемных, а также запуск консоли непосредственно в директории разработки. В остальном - это обычные стандартные консоли Windows, включая, как показано ранее, установленную кодовую страницу по умолчанию.
Отдельной опцией Visual Studio является встроенная односеансная консоль отладки, которая перехватывает команду Visual Studio на запуск приложения, запускается сама, ожидает компиляцию приложения, запускает его и отдает ему управление. Таким образом, отладочная консоль в течение всего рабочего сеанса находится под управлением приложения и возможность использования команд Windows или самой консоли, включая команду CHCP, не предусмотрена. Более того, отладочная консоль не воспринимает кодовую страницу по умолчанию, определенную в реестре, и всегда запускается в кодировке 437 или 866.
Совет 6. Тестирование приложения целесообразно выполнять во внешних консолях, более дружелюбных к локализации.
Анализ проблем консолей был бы не полон без ответа на вопрос - можно ли запустить консольное приложение без консоли? Можно - любой файл ".exe" запустится двойным кликом, и даже откроется окно приложения. Однако консольное приложение, по крайней мере однопоточное, по двойному клику запустится, но консольный режим не поддержит - все консольные вводы-выводы будут проигнорированы, и приложение завершится
Локализация отладочной консоли Visual Studio
Отладочная консоль - наиболее востребованная консоль разработчика, гораздо более удобная, чем внешняя консоль, поэтому резонно приложить максимум усилий для ее локализации.
На самом деле, правильнее говорить о локализации приложения в консоли - это важное уточнение. Microsoft по этому поводу высказывается недвусмысленно: "Programs that you start after you assign a new code page use the new code page. However, programs (except Cmd.exe) that you started before assigning the new code page will continue to use the original code page". Иными словами, консоль можно локализовать когда угодно и как угодно, но приложение будет локализовано в момент стабилизации взаимодействия с консолью в соответствии с текущей локализацией консоли, и эта локализация сохранится до завершения работы приложения. В связи с этим возникает вопрос - в какой момент окончательно устанавливается связь консоли и приложения?
Важно! Приложение окончательно стабилизирует взаимодействие с консолью в момент начала ввода-вывода в консоль, благодаря чему и появляется возможность программного управления локализацией приложения в консоли - до первого оператора ввода-вывода.
Ниже приведен пример вывода тестового приложения в консоль, иллюстрирующий изложенное. Метод Write получает номера текущих страниц, устанавливает новые кодовые страницы вводного и выводного потоков, выполняет чтение с консоли и записывает выводную строку, содержащий русский текст, в том числе считанный с консоли, обратно в консоль. Операция повторяется несколько раз для всех основных кодовых страниц, упомянутых ранее.
приложение запущено в консоли с кодовыми страницами 1251 (строка 2);
приложение меняет кодовые страницы консоли (current, setted);
приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);
по окончании работы приложения изменения консоли сохраняются (строка 14 - Active codepage 1252);
Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).
Совет 7. Обязательный и повторный! Функции SetConsoleCP должны размещаться в коде до первого оператора ввода-вывода в консоль.
Стратегия локализации приложения в консоли
Удалить приложение PowerShell (если установлено), сохранив Windows PowerShell;
Установить в качестве кодовую страницу консоли по умолчанию CP65001 (utf-8 Unicode) или CP1251 (Windows-1251-Cyr), см. совет 5;
Разработку приложений выполнять в кодировке utf-8 Unicode;
Контролировать кодировку файлов исходных кодов, текстовых файлов данных, например с помощью Notepad++;
Реализовать программное управление локализацией приложения в консоли, пример ниже под катом:
В Visual Studio 2019 есть две оболочки командной строки для разработчиков:
Командная строка разработчика для Visual Studio — стандартная командная строка с определенными переменными среды, упрощающая работу с инструментами разработки. Доступно с версии Visual Studio 2015.
PowerShell для разработчиков Visual Studio — более функциональное средство, чем командная строка. Например, в нем можно передать результат одной команды (называемой cmdlet ) в другой cmdlet. В этой оболочке доступны те же переменные среды, что и в Командной строке разработчика. Доступно с версии Visual Studio 2019.
Начиная с версии 16.5, в Visual Studio 2019 доступен встроенный терминал, где можно работать как с Командной строкой разработчика, так и с PowerShell для разработчиков. Можно открыть несколько вкладок для каждой оболочки. Терминал Visual Studio построен на основе Терминала Windows. Чтобы открыть терминал в Visual Studio, выберите элементы Вид > Терминал.
При запуске в Visual Studio одной из оболочек как отдельного приложения или в окне терминала открывается каталог текущего решения (если оно загружено). Это упрощает выполнение команд для решения или его проектов.
В обеих оболочках заданы определенные переменные среды. Это упрощает работу с инструментами командной строки. Открыв эти оболочки, можно выполнять команды для различных служебных программ, не указывая их расположения.
Запуск в Visual Studio
Выполните следующие действия, чтобы открыть в Visual Studio Командную строку разработчика или PowerShell для разработчиков:
Запустите Visual Studio.
В строке меню выберите элементы Инструменты > Командная строка > Командная строка разработчика или PowerShell для разработчиков.
Запуск из меню Windows
Другой способ запуска оболочек — из меню "Пуск". В зависимости от версии Visual Studio, дополнительно установленных пакетов SDK и рабочих нагрузок может иметься несколько вариантов командных строк.
Windows 10
Выберите Пуск и прокрутите до буквы V.
Разверните папку Visual Studio 2019.
Выберите вариант Developer Command Prompt for VS 2019 (Командная строка разработчика для VS 2019) или Developer PowerShell for VS 2019 (PowerShell для разработчиков для VS 2019).
Кроме того, вы можете начать вводить имя оболочки в поле поиска на панели задач и выбрать нужный результат, так как в списке результатов начнут отображаться найденные совпадения.
Windows 8.1
Перейдите на экран Пуск, нажав клавишу с логотипом Windows на клавиатуре, например.
На начальном экране нажмите Ctrl+Tab, чтобы открыть список приложений, а затем нажмите V. Появится список, включающий все установленные командные строки Visual Studio.
Выберите вариант Developer Command Prompt for VS 2019 (Командная строка разработчика для VS 2019) или Developer PowerShell for VS 2019 (PowerShell для разработчиков для VS 2019).
Windows 7
Выберите Пуск а затем разверните Все программы.
Выберите элементы Visual Studio 2019 > Инструменты Visual Studio > Developer Command Prompt for VS 2019 (Командная строка разработчика для VS 2019) или Developer PowerShell for VS 2019 (PowerShell для разработчиков для VS 2019) .
Если установлены другие пакеты SDK, например, пакет SDK для Windows 10 или предыдущих версий, могут появиться дополнительные командные строки. Требуемая версия командной строки указана в документации по соответствующим инструментам.
Запуск из обозревателя файлов
Обычно ярлыки для установленных оболочек помещаются в папку меню "Пуск" для Visual Studio, например в %ProgramData%\Microsoft\Windows\Start Menu\Programs\Visual Studio 2019\Visual Studio Tools. Но если поиск командной строки не дает ожидаемых результатов, попробуйте вручную найти нужные файлы на компьютере.
Командная строка разработчика
Выполните поиск файла командной строки (VsDevCmd.bat) или перейдите в папку "Инструменты" Visual Studio ( %ProgramFiles(x86)%\Microsoft Visual Studio\2019\Community\Common7\Tools — путь зависит от версии Visual Studio, выпуска и расположения установки).
Когда вы найдете файл командной строки, откройте его. Для этого введите следующую команду в стандартном окне командной строки:
Кроме того, вы можете ввести следующую команду в диалоговом окне Windows Выполнить:
Вам необходимо изменить путь в соответствии с расположением установки Visual Studio.
Есть ли какие-нибудь красивые решения вывода каких-либо данных во время дебага winform приложения? Т.е. допустим выполняя какие либо действия, не открывая окна студии увидеть числовые значения переменных. Может можно консоль как-то рядом запустить?
Добавлено через 10 минут
С консолью разобрался
Во время отладки в Visual Studio 2015 при просмотре хедеров возникает ошибка: чтение памяти невозможно
При отладке в Visual Studio 2015 невозможно просмотреть содержимое переменных! Пишет "Чтение.
Visual studio на ошибке выходит из отладки
Простой код: private void Form1_Load(object sender, EventArgs e) < .
Появление окна отладки Visual Studio после запуски GTA 4
проблема: хочу например поиграть в gta 4, при запуске не дает запустится visual studio 2005.
При запуске отладки Visual Studio 2013 выдает ошибку
Всем доброго времени суток. Вчера установил windows 7 x64 и visual studio 2013. И теперь при.
skilllab, звучит просто "как изящно удалить гланды через задницу. Проблема в том, что пользоваться скальпелем (VS) нельзя".
У вас есть студия - стандартное приложение, для этих дел. Если нету студии - пишите те же логи, log4net тот же взять можно. Или самому File.AppendAllLines.
Есть же специально обученная программа для чтения дебага (это когда вывод через класс Debug делается).Видел, как для этого используют log4net - SmartInspect. В отдельной программе бегут строчки с логами, которые прилетают с разных приложений, либо с разных серверов либо с разных нод кластера. Удобная, легко конфигуримая штуковина.
Ещё как-то я хитрый лог видел, который протоколирует исключения и в отдельной гляделке их можно ретроспективно, либо в реальном времени просматривать и фильтровать:
А вообще для отладки большинства приложений достаточно дебага в студии, для ретроспективного анализа можно просто лог писать, и не стоит из этой задачи делать проблему, Psilon уже наглядно это объяснил.
Запускаем visual studio. Создаем новый проект:
вводим имя приложения FirstApp, остальное в этот раз можно не трогать, жмем Ok.
Откроется код приложения. Так как у нас приложение пока самое простое, оно состоит из одного файла:
Разбор кода
Тут может встретиться куча странных и непонятных слов, в принципе этот раздел можно пропустить.
Добавляем вывод в консоль
Запустим программу, нажав кнопку пуск
Затем откроется окно консоли и тут же закроется. Это, между прочим, была наша программа в действии.
Открывается и закрывается окно потому, что наше приложение пока еще ничего не умеет.
Давайте выведем чего-нибудь в консоль. Для этого воспользуемся классом Console, которые находится в пакете System (именно для этого и нужна строчка using System), и так:
запускаем приложение, либо кликая на кнопку Пуск либо нажав F5.
Снова что-то проскакивает, но уже с нашим текстом, но все равно быстро закрывается.
Надо как-нибудь остановить процесс мгновенного закрытия программы. Для этого заставим программу ждать нажатия любой клавиши от пользователя, правим приложение:
Отлично! Теперь программа напечатал текст, и остановилась – ждет пока пользователь чего-нибудь нажмет.
Жмем любую клавишу, и программа тут же закрывается.
Исполняемый файл приложения
Итогом компиляции приложения является *.exe файл, именно этот файл запускается, когда нажимаешь кнопку пуск. Точнее, сначала этот файл создается, а потом уже запускается. Сам файл лежит по пути, который был указан при создании проекта.
В моем случае я указал имя приложения FirstApp, а путь к проекту C:\Users\m\source\repos . Таким образом exe файл находится в папке c:\Users\m\source\repos\FirstApp\FirstApp\bin\Debug\
Вы можете запустить приложение FirstApp и убедится, что он действительно является вашей программой.
Читайте также: