Я должен включать режим командной строки в свои приложения?
Не злоупотребляйте символами.
Каждый раз, когда Вы создаете символ, рубин вставляет запись, это - таблица символов. Таблица символов является глобальным хешем, который никогда не освобожден.
Это не технически утечка памяти, но она ведет себя как одна. Символы не поднимают много памяти, таким образом, Вы не должны быть слишком параноиками, но она платит для знания об этом.
общее руководство А: при фактическом вводе символа в коде он прекрасен (у Вас только есть конечный объем кода, в конце концов), но не обращайтесь к to_sym, динамично сгенерированному или строки ввода данных пользователем, поскольку это открывает дверь в потенциально постоянно увеличивающийся номер
9 ответов
На самом деле иметь приложение C # как консольное, так и GUI проблематично. Консольные приложения ( / t: exe ) запускаются, а затем командная строка ожидает их завершения. Приложения с графическим интерфейсом ( / t: winexe ) командная оболочка запускает их, а затем немедленно возвращает. Хотя вы можете создавать и запускать формы из «консольного» приложения, в нем всегда будет отображаться фоновая консоль. С другой стороны, приложение Forms не имеет стандартного ввода, stdout и stderr подключены, и, хотя они могут вести себя как инструменты командной строки и обрабатывать аргументы команд, у них возникают проблемы при встраивании в сценарии (поскольку стандартный ввод / вывод не подключен).
Если вы хотите раскрыть функциональность как приложений, управляемых графическим интерфейсом, так и пакетной обработки с поддержкой сценариев / конвейеров, лучший способ - это скомпилировать вашу функциональность в библиотеку классов, а затем создать два отдельных приложения (одно GUI и одну консоль), которые эта библиотека.
Я не программист на C # , но когда я программирую на C ++, я считаю наиболее полезным:
1.) Создать как общую библиотеку с C, так и C ++ API для выполнения основных функций приложения.
2.) Создать одну или несколько двоичные файлы командной строки, доступные интерпретатору оболочки.
3.) Создайте приложение с графическим интерфейсом пользователя для типичных конечных пользователей, реализованное с помощью библиотеки (не вызывая двоичные файлы).
Это отделяет логику приложения от интерфейса до интерфейса. application, и позволяет сторонним разработчикам создавать альтернативные интерфейсы для тех же функций приложения. Он также упрощает создание сценариев и в то же время обслуживает типичных конечных пользователей, которым нужен красивый, блестящий графический интерфейс.
Да. Если вы думаете, что программа будет полезна в среде со сценариями, включите режим командной строки (без пользовательского интерфейса), чтобы ее можно было использовать в сценариях.
Это не обязательно должно быть отдельное приложение, но может быть. Хотите вы это сделать или нет - решать вам. Я полагаю, что если бы у вас было два приложения, они использовали бы одни и те же логические сборки, но интерфейс (одно - графический интерфейс, другое - командная строка) был бы просто другим.
I agree with michaelsafyan about creating a library with core functionality.
What I would add is that you should check out powershell cmdlets as well.
Much command line activity will be migrating to powershell and it brings a lot to the table.
Создание приложения на платформе Windows, которое ведет себя правильно как консольное приложение, может быть проблематичным. Это проблема с архитектурой ядра Windows, поскольку они считаются двумя разными типами приложений (у них разные подсистема, которую вы обычно указываете в параметрах компилятора или компоновщика). Вы все еще можете вручную перенаправить ввод-вывод и открыть консоль из приложения win32 с помощью функции Win32 AllocConsole () и ее друзей, но это также имеет некоторые проблемы. Для получения дополнительной информации см. Это сообщение Old New Thing .
Если вы хотите, чтобы ваша утилита / программа запускалась в сценариях, вы можете выставить их как COM.
Многие языки сценариев для Windows имели возможность напрямую использовать COM-объекты.
Очень часто я создаю такую утилиту, как API. Если мне нужно использовать его из простой утилиты командной строки, это просто - он просто вызывает API. Если командная строка становится слишком сложной, возможно, пришло время для приложения Winforms, которое также может вызывать API. Если бы я хотел использовать его из PowerShell или из задачи MSBUILD, это все равно было бы просто - они просто вызывают API.
Я согласен с @Remus Rusanu.
вам следует создать библиотеку классов для своей основной функциональности, а затем создать приложение (оболочку) с графическим интерфейсом для этого.
и еще одно ее преимущество. вам может даже не понадобиться создавать приложение командной строки, поскольку вы можете получить доступ к функциям .net dll с помощью powershell ..
вы можете найти один пример по здесь
Еще одна замечательная идея - встроить язык сценариев. Тогда вашей программой можно будет управлять с помощью сценария, и вы получите всю логику, ветвления и т. Д. Из языка сценариев «бесплатно».
Есть много вариантов того, что вы можете встроить. Lua - один из самых популярных и предназначенных именно для этой цели, и это отличный выбор.
Однако для приложения общего назначения я бы внимательно посмотрел на встраивание Python. Python настолько популярен, что у вас будет большая группа людей, готовых написать сценарий для вашего приложения.