Консольное приложение (аля FAR)

Привет всем мегамозгам программирования. Вы, ребята, реально выручаете всегда. Прошу подсказки, хочу для себя написать консольное приложение где стиль управления и отображения данных будет реализован в духе программы Far Manager.
Исходники Far смотрел, но там не мой уровень, ничего не понял. Когда-то на Clipper писал программы, там вот окошечки, менюшки довольно ловко рисовались, а вот как это в C# сделать?

0

Сообщение от nicolas2008 Если убрать эту информацию, как вы предложили

о_О где? Я вообще не касался темы dll

0

Сообщение от belalugoci мда, оказывается для каждого проекта нужно ставить пакеты снова. странная парадигма.

Как VS узнает какая версия библиотеки нужна каждому конкретному проекту, если бы ссылки на пакеты добавлялись на уровне VS/системы, а не на уровне конкретного проекта?

Ну и к сведению: во первых не uses, а using, во вторых using не имеет ничего общего с библиотеками, это просто средство чтобы вам меньше приходилось писать в плане имен типов.

0

Сообщение от Someone007 Как VS узнает какая версия библиотеки нужна каждому конкретному проекту

А как Photoshop узнает какую версию фильтра применять к изображению? Вы для каждой фотографии устанавливаете фильтры снова и снова? Или всё же ставите фильтры один раз, а внутри каждого проекта только выбираете параметры его работы?
Если вы вдруг запамятовали, то выбор версии .NET именно так и происходит, он ставится в VS а в свойствах проекта вы можете менять версию, если вдруг такая необходимость появилась.
Точно так же с Python или Java - они ставятся единожды, а потом лишь каждый выбирает то что ему нужно. Это очевидно, и не ясно с чего это у вас вызывает вопросы.

0

Сообщение от belalugoci А как Photoshop узнает какую версию фильтра применять к изображению? Вы для каждой фотографии устанавливаете фильтры снова и снова? Или всё же ставите фильтры один раз, а внутри каждого проекта только выбираете параметры его работы?

Понятия не имею что там в фотошопе, т.к. не пользуюсь данным софтом. Но если рассуждать логически, то фильтры должны применяться к каждой фотографии отдельно.

Сообщение от belalugoci Если вы вдруг запамятовали, то выбор версии .NET именно так и происходит, он ставится в VS а в свойствах проекта вы можете менять версию, если вдруг такая необходимость появилась.

Можете, только как это связано с nuget пакетами, которые сами по себе? nuget пакеты тоже кстати имеют версии. Как VS должна узнать какой версии nuget пакет нужно использовать в каждом конкретном проекте?

Сообщение от belalugoci Точно так же с Python или Java - они ставятся единожды, а потом лишь каждый выбирает то что ему нужно.

В питоне тоже есть пакеты и они насколько мне известно тоже ставятся отдельно в каждый проект...

0

Сообщение от Someone007 Но если рассуждать логически, то фильтры должны применяться к каждой фотографии отдельно.

ставятся 1 раз, а потом применяются (using)

Сообщение от Someone007 Можете, только как это связано с nuget пакетами

видимо так же как и ваши рассуждения про dll

Сообщение от Someone007 nuget пакеты тоже кстати имеют версии

боюсь подумать что будет с проектом сделанным в VS2017 при попытке открыть его в VS2019. Видимо придется ставить VS2017 и работать так всю оставшуюся жизнь.

Сообщение от Someone007 Как VS должна узнать какой версии nuget пакет нужно использовать в каждом конкретном проекте?

По умолчанию самая последняя версия если пользователем не указано иное. Вы первый раз с ПК и ПО взаимодействуете?

Сообщение от Someone007 В питоне тоже есть пакеты и они насколько мне известно тоже ставятся отдельно в каждый проект...

Когда один про зеленое, а второй про мягкое - можно разговаривать бесконечно, выискивая точки соприкосновения.

Вот ваш вариант:
1) Берем VS
2) Создаем проект
3) Ставим Nuget пакет
4) Повторяем 2-3 еще 1000 раз, пока не наступит катарсис

Вот мой вариант:
1) Берем VS
2) Ставим Nuget пакет
3) Создаем проект
4) Повторяем 3 tot 1000 раз
5) По необходимости выбираем версию пакета

Как мне кажется мой вариант очевидно более удобен в работе.

0

Сообщение от belalugoci ставятся 1 раз, а потом применяются (using)

nuget пакеты тоже 1 раз ставятся. Потом добавляются в каждый конкретный проект через меню Manage nuget packages... или Manage nuget packages for Solution...
using тут вообще не причем...

Сообщение от belalugoci видимо так же как и ваши рассуждения про dll

А я про DLL ничего не говорит вообще, хватит придумывать...

Сообщение от belalugoci боюсь подумать что будет с проектом сделанным в VS2017 при попытке открыть его в VS2019. Видимо придется ставить VS2017 и работать так всю оставшуюся жизнь.

Может и придется, но скорее всего нет.

Сообщение от belalugoci По умолчанию самая последняя версия если пользователем не указано иное. Вы первый раз с ПК и ПО взаимодействуете?

Это совсем не очевидно. Как и где по вашему нужно указывать? Ну и раз пользователю нужно указывать версию, то и версию чего именно не мешало бы указать, что и делается через меню Manage nuget packages... или Manage nuget packages for Solution...
В большинстве случаев можно даже обойтись без использования меню Manage nuget packages, просто кликнув на подсказку в коде...

Сообщение от belalugoci Когда один про зеленое, а второй про мягкое - можно разговаривать бесконечно, выискивая точки соприкосновения.

Не понимаю о чем вы вообще...

Сообщение от belalugoci 1000 раз

Сообщение от belalugoci 1000 раз

Вы в день по 1000 проектов создаете или по 1000 nuget пакетов добавляете? Мне вас жаль (нет).

Сообщение от belalugoci Как мне кажется мой вариант очевидно более удобен в работе.

Именно что кажется, а на самом деле это не так.

Добавлено через 8 минут
И вот например такая ситуация (если бы nuget пакеты как вы хотите автоматически во все проекты добавлялись):
есть nuget пакет A, он используется в проектах A, B, C и т.д. с версией по умолчанию (самая последняя).
Вы работаете допустим над проектом A и видите что вышла новая версия nuget пакета A, обновляете его и вдруг в ваших проектах B и C тоже версия nuget пакета обновилась. А потом выясняется что в новой версии nuget пакета есть breaking changes и ваши проекты B и C больше не компилятся или работают не так как работали с прежней версией nuget пакета A...

Ну и еще раз, using это не добавление DLL, nuget пакета или еще чего либо. Это просто для удобства, чтобы вам было меньше писать.

0

Сообщение от Someone007 nuget пакеты тоже 1 раз ставятся. Потом добавляются в каждый конкретный проект через меню Manage nuget packages... или Manage nuget packages for Solution...

Это не так, смотрите скриншот, пакета нет, но я уже ставил его для двух проектов.

Сообщение от Someone007 using тут вообще не причем...

аналогия с include, пока не укажете VS знать не будет что именно вы хотите.

Сообщение от Someone007 А я про DLL ничего не говорит вообще, хватит придумывать...

да тут вся ветка про dll, даже не знаю причем тут dll

Сообщение от Someone007 Может и придется, но скорее всего нет.

свой первый компилятор я использовал с 1987 году и пока ни разу не было случая описываемого вами, статистика как-никак, а уж сколько языков перепробовано...

Сообщение от Someone007 Это совсем не очевидно

Так работает во всех программах. Это очевидно.

Сообщение от Someone007 Как и где по вашему нужно указывать?

Где хотите, раз до сих пор нет такой реализации - придумайте. Можно в том же using указать например.
using Terminal.Gui -v 0.24.0

Сообщение от Someone007 Ну и раз пользователю нужно указывать версию, то и версию чего именно не мешало бы указать

Смысле?

Сообщение от Someone007 Вы в день по 1000 проектов создаете или по 1000 nuget пакетов добавляете? Мне вас жаль (нет).

Это пример. За два дня три раза создавал приложение и нужно было добавлять пакеты, это он один, а если их 20?
А мне жаль вас, что для вас простые и очевидные вещи не просто не непонятны, а вы еще и защищаете извращенный способ работы.

Сообщение от Someone007 Именно что кажется, а на самом деле это не так.

За последние 15 лет я из ИТшника несколько перепрофилировался в эдакого специалиста-оптимизатора. С опытом на многие вещи смотришь иначе и когда приходишь на новое место а там взрослые люди ведут себя хуже детей, то невольно приходится им показывать как правильно. Поверьте, они все уверены что я маюсь дурью и у них всё и без меня удобно. Так что каждый останется при своём мнении, но я удоство своего подхода обосновал, вы - нет.

Сообщение от Someone007 И вот например такая ситуация (если бы nuget пакеты как вы хотите автоматически во все проекты добавлялись):

Враньё на пустом месте, я ни слова не сказал про автоматическое добавление Nuget пакетов во все проекты.

Сообщение от Someone007 есть nuget пакет A, он используется в проектах A, B, C и т.д. с версией по умолчанию (самая последняя). Вы работаете допустим над проектом A и видите что вышла новая версия nuget пакета A, обновляете его и вдруг в ваших проектах B и C тоже версия nuget пакета обновилась. А потом выясняется что в новой версии nuget пакета есть breaking changes и ваши проекты B и C больше не компилятся или работают не так как работали с прежней версией nuget пакета A...

Это называется - чтобы мне придумать такое чтобы придумать и чтобы придуманное было придуманным, а потом я скажу что это всё фигня и всем станет очевидно, так как придуманное придуманное не может быть не фигней.

кто вам мешает сделать опцию, где вы по желанию можете указать, чтобы обновления не применялись?
А вообще, как я и написал выше - не будем рассуждать на тему ваших абсурдных фантазий.

Сообщение от Someone007 Ну и еще раз, using это не добавление DLL, nuget пакета или еще чего либо

А я нигде такое и не говорил. Это ссылка про пространство имён, чтобы понимать что например Path можно найти в System.IO.
Но очевидно, что компилятор в работе будет руководствоваться тем что там написано. А то что вы используете попадет в конечный файл. Надеюсь не вызывает споров что using Terminal.Gui приведет к компиляции кода в этом файле/наборе файлов и конечный EXE будет содержать используемые в моей программе методы?.

0

Сообщение от belalugoci Это не так, смотрите скриншот, пакета нет, но я уже ставил его для двух проектов.

Там отображаются пакеты, добавленные в проект, а не закэшированные у вас в системе.

Сообщение от belalugoci аналогия с include, пока не укажете VS знать не будет что именно вы хотите.

Даже близко нет.

Сообщение от belalugoci да тут вся ветка про dll, даже не знаю причем тут dll

А по моему мы тут nuget пакеты обсуждаем.

Сообщение от belalugoci Так работает во всех программах. Это очевидно.

Нет, так работает далеко не во всем программах, как бы вы этого не хотели...

Сообщение от belalugoci Где хотите, раз до сих пор нет такой реализации - придумайте. Можно в том же using указать например. using Terminal.Gui -v 0.24.0

using не для этого придумали. Сейчас все ссылки указываются в каждом конкретном файле проекта.

Сообщение от belalugoci Смысле?

В прямом.

Сообщение от belalugoci но я удоство своего подхода обосновал

Ничего вы не обосновали, вы только и говорите "хочу вот так и больше никак"...

Сообщение от belalugoci Враньё на пустом месте, я ни слова не сказал про автоматическое добавление Nuget пакетов во все проекты.

По вашим словам именно за это вы тут и ратуете... А так же до вас до сих пор не дошло что такое using и для чего оно нужно... Иначе бы все вопросы давно отпали.

Сообщение от belalugoci не будем рассуждать на тему ваших абсурдных фантазий

Это были бы реалии, если бы nuget пакеты работали как вы хотите.

Сообщение от belalugoci А я нигде такое и не говорил. Это ссылка про пространство имён, чтобы понимать что например Path можно найти в System.IO.

Именно. Пространство имен. Не nuget пакет, ни DLL, ни сборка, ни что либо еще...
А вы почему-то до этого утверждали что using должен подключать вам в проект nuget пакеты. Это в принципе не возможно... Хотя бы по причине того, что одно и тоже пространство имен может быть в неограниченном количестве nuget пакетов или сборок. Да и одноименные типы могут находится в разных пространствах имен. Тот же Path например...

0

Сообщение от Someone007 А вы почему-то до этого утверждали что using должен подключать вам в проект nuget пакеты

Где?

0

Сообщение от belalugoci Где?

Да прямо вот тут Консольное приложение (аля FAR)

0

Сообщение от Someone007 Да прямо вот тут

и где там хоть пол слова про Nuget и то что using подключает сторонние пакеты? Вы хоть контекст моего ответа читайте.

0

и еще тут

Сообщение от belalugoci ставятся 1 раз, а потом применяются (using)

Сообщение от belalugoci Можно в том же using указать например. using Terminal.Gui -v 0.24.0

Добавлено через 1 минуту

Сообщение от belalugoci и где там хоть пол слова про Nuget и то что using подключает сторонние пакеты? Вы хоть контекст моего ответа читайте.

Вы же сами говорили что мы тут DLL (библиотеки) обсуждаем. Что уже нет? nuget пакет это по сути библиотека (или их набор)....

Сообщение от belalugoci да тут вся ветка про dll, даже не знаю причем тут dll

Сообщение от belalugoci поэтому логично ставить библиотеку в сам VS, а указывая uses Terminal.Gui говорить, что конкретно использовать

0

Сообщение от Someone007 Вы же сами говорили что мы тут DLL (библиотеки) обсуждаем. Что уже нет?

вернитесь в самое начало, внимательно перечитайте, я вообще ни слова про dll ни сказал, я наоборот пытался спросить причем тут dll вообще. Кто-то неудачно пукнул про dll и теперь мы их только и обсуждаем.

Сообщение от Someone007 и еще тут

и где там про Nuget?

Сообщение от Someone007 поэтому логично ставить библиотеку в сам VS, а указывая uses Terminal.Gui говорить, что конкретно использовать

И? Библиотеки вообще-то это библиотеки языка программирования, а не dll, dll - это динамически подключаемые библиотеки на уровне приложения и я не вижу чтобы Terminal.Gui поставлялся в виде dll и чтобы я в своем проекте подключал её и вызывал внешние функции.

0

Сообщение от belalugoci Библиотеки вообще-то это библиотеки языка программирования, а не dll

Т.е. все эти dll которые идут вместе с .NET Framework это не библиотеки языка программирования? Что это тогда? Есть конкретные примеры библиотек языка программирования C#?

Сообщение от belalugoci я не вижу чтобы Terminal.Gui поставлялся в виде dll и чтобы я в своем проекте подключал её и вызывал внешние функции

Плохо что не видите, потому что именно так это и работает...

0

Сообщение от Someone007 поэтому логично ставить библиотеку в сам VS

возможно вам не довелось программировать под DOS, тогда расскажу, библиотеки функций входили в состав IDE и компилятора и при написании приложения вы могли использовать готовое. На данный момент namespaces такую функцию и выполняют, только все библиотеки сосредоточены в ядре .NET и по сути using кроме сокращения написания либо предоставляет готовое решение либо является ссылкой на решение внутри .NET.
Реализована это через dll сейчас или нет, мне совершенно по барабану, хоть закодированными пикселами в квантовом поле.
Если вы хотите добавить в своё приложение какой функционал, то вы берете готовое решение, например Terminal.Gui, что вполне соответствует в терминологии - библиотеке классов.
Если вам не нравится термин библиотека, не используйте, а я уж как-то буду по-старинке, ибо в тему.

Добавлено через 10 минут

Сообщение от Someone007 Плохо что не видите, потому что именно так это и работает...

полез изучать...
ну что скажу, после изучения вопроса я теперь еще более худшего мнения о реализации такого подхода, мало того что Nuget пакет действительно ставится в скомпилированном DLL виде, так еще он болтается отдельным файлом рядом с файлом проекта и без него не запускается. Придумал это весьма укуренный человек.
Про DLL я изначально не подумал, так как скачивал проект с GIT и мне показалось что он лежит в виде CS файла, что было бы логично.

0

Сообщение от belalugoci библиотеки функций входили в состав IDE и компилятора и при написании приложения вы могли использовать готовое

Можно подумать сейчас что-то изменилось...

Сообщение от belalugoci using кроме сокращения написания либо предоставляет готовое решение либо является ссылкой на решение внутри .NET

Нет. Если у вас к проекту не добавлена соответствующая ссылка на библиотеку классов/nuget пакет/sdk/framework с нужным функционалом, то using вам ничего не предоставит, т.к. кроме сокращения написания имен типов он ничего не делает.

Сообщение от Someone007 я не вижу чтобы Terminal.Gui поставлялся в виде dll

Сообщение от belalugoci готовое решение - Terminal.Gui - библиотеке классов.

Так в каком виде у вас поставляется Terminal.Gui? Библиотека классов? DLL? Что-то еще?

Добавлено через 3 минуты

Сообщение от belalugoci он болтается отдельным файлом рядом с файлом проекта и без него не запускается

О, походу еще один адепт запихивания всего и вся в один исполняемый файл

Добавлено через 1 минуту

Сообщение от belalugoci Про DLL я изначально не подумал, так как скачивал проект с GIT и мне показалось что он лежит в виде CS файла, что было бы логично.

Т.е. по вашему все библиотеки, nuget пакеты, компоненты должны в исходниках поставляться?

Добавлено через 2 минуты
Я вас еще огорчу, т.к вы наверняка не знаете, так вот если вы даже из исходников компилите, то в exe попадает абсолютно весь код из проекта, даже тот, который не используется.

0

Сообщение от Someone007 О, походу еще один адепт запихивания всего и вся в один исполняемый файл

XD нет на самом деле, просто в ряде случае удобнее иметь один файл
PS: помнится у меня был первый проект на делфи размером 35 кажется мегабайт и я мог его запустить только дома, так как у меня оперативки было 64, а вот преподу в ВУЗе уже показать не мог, он не запускался из-за нехватки памяти.
Позднее, не для уменьшения размера в памяти а для уменьшения размера таскаемого файла пользовался сжатием EXE файла программой UPX.

Сообщение от Someone007 Т.е. по вашему все библиотеки, nuget пакеты, компоненты должны в исходниках поставляться?

бесплатные - да

Сообщение от Someone007 Я вас еще огорчу, т.к вы наверняка не знаете, так вот если вы даже из исходников компилите, то в exe попадает абсолютно весь код из проекта, даже тот, который не используется.

На TASM в своё время писали программу которая от EXE отрезала ненужные библиотеки после компиляции и сборки.

Мне кажется мы всё обсудили что имело и не имело смысла. Ваши слова меня в очередной раз разочаровали, я уж думал за столько то лет могли бы хоть с места сдвинуться в решении простых вопросов, ан нет.

0