Пока программно тему не копал.
Есть идея утилитки.
Смысл, чтоб она могла запускаться и в режиме консоли, и в режиме "НЕ консоли", в зависимости от параметра командной строки.

Консоль нужна например если
1) делать туда вывод событий
2) если запуск в режиме bat-файла, то он будет ждать завершения и только потом переходить к след. команде

Консоль НЕ нужна например если
1) вывод в нее не нужен
2) черное ее окно на экран не нужно
и т.д.

О GUI типа формы на экран речь не идет, форму можно вызвать из main() и для консольного приложения, речь не об этом.

Грубо, хочу так (в свойствах проекта предположительно "Приложение Win Form + Sub Main")



МОЖНО или НЕ МОЖНО?

2 проекта не хочу, там очень много всего а логика одинаковая (что с консолью, что без), сложно будет потом "параллельно поддерживать".

fkthatКраткий ответ - нет (если не использовать нативный Win API, про который выше упоминали).
м-м-м
счас глянул свои старые VB6 коды, именно так и было сделано одно из приложений


А когда переписывал на .Net от API отказался в пользу "Консольное приложение".
И вилку эту убил.
Видимо придется реанимировать.

ИзопропилНе может. Флаг отвечающий за это находится в PE заголовке
Я понял ответ, спасибо.

ИзопропилAllocConsole применить можно, но могут быть проблемы с перенаправлением ввода-вывода
Не будет проблем. В VB6 так делал. Это нормальный вариант.

Но в .Net будут некоторые непреодолимые издержки (в том числе и при "консольном" через AllocConsole запуске), вот вспомнил свой пост:
Простое приложение без GUI выдает свою активность (песочные часики).

Хотя в данном случае можно забить, в силу специфики кухни этих часиков там и так будет, хоть и из чисто консоли.

Petro123Я сам теряюсь что ему нужно
Все просто.
Приложение SendFax.exe -размещает задание в MS службу факсов + [ опционально отслеживает как идет конкретно процесс отправки этого факса] Через FaxCOMEx ("часиков" на этапе создания задания по любому не избежишь)
На входе куча параметров через cmd: номер, отправляемый документ, + всякие титульные страницы, Sender Info, много там всего.

А "что ему нужно" зависит от хотелок юзера.

Если нужно где-нибудь (в Excel-е, своей проге) щелкнуть кнопку и любоваться как идет/дошел этот самый единственный факс, то подойдет красивое GUI окошко где будет писаться Dialing-Sending page-Retrying и рисоваться свистелки, и консоль нафиг не нужна.

А если например последовательная отправка по списку,
то например bat-файл с переходом к след. строчке после выполнения предыдущей, и консоль самое то.
Ну опционально можно отслеживать коротким выводом в консоль типа
Dialing...
Sending page 1 of 3
Sending page 2 of 3
…

Основная сложная логика
1) Грамотная обработка входных параметров cmd - создание задания
2) Опциональная часть с отслеживанием статистики отправки этого задания

Petro123Ну, по всему приложению считай нужно писать в каком режиме оно работает.
И че, один параметр bConsoleMode=true/false вычисляемый сразу же.
==
В общем слегка конкретизировал, чего конкренто делаю. Пока логикой и GUI отслеживания событий занимаюсь, там посмотрим как сделаю с консоль/не консоль. Суть ответов по существу понял. Спасибо.

Дошли руки до реализации.
Фигово получается.

Тупо AllocConsole() как я делал в VB6 не катит.
При запуске из bat-файла или cmd оно плодит новую консоль.

Катит (как сперва показалось ) вот такой вариант что даже стандартные Console.xxx работают (WinForm+Main()):



При тупо запуске мышкой все OK (AllocConsole).
При вызове из bat-файла тоже все корректно (AttachConsole).

НО При вызове из cmd - фигня какая-то,
AttachConsole вроде срабатывает, вывод идет,
но Console.ReadKey не ловится, вместо этого как бы выразиться, cmd сразу "подставляется под ввод новой команды",
сам мой exe-шник закушен (пока консоль не закроешь),
короче бред-мрак, не годится.

Подкоректировать как то можно?

Обратный вариант с "Консольное приложение" + сразу FreeConsole (если "без консоли") - ну не охота с "Мигалкой консоли".

Компилировать 2 раза (2 разные имени) - можно, но как то некрасиво
(ну понятно, что вообще один код можно сделать и только тип проекта менять перед компиляцией)

В VB6 достаточно было либо просто AllocConsole (и оно корректно присасывалось к родительской консоли при наличии без всякого Attach), либо отсутствие AllocConsole (и оно запускалось как "неконсольное").

Че придумать то?

ИзопропилДмитрий77Компилировать 2 раза (2 разные имени) - можно, но как то некрасиво
(ну понятно, что вообще один код можно сделать и только тип проекта менять перед компиляцией)msbuild используй
некрасив сам факт, что exe-шника будет 2,
а делать один из другого и ручками недолго (поменять тип проекта + м.б. один параметр в коде ConsoleMode=True/False)

Видимо я пока остановлюсь на варианте WinForm + ключ /Console + AllocConsole/AttachConsole.
Это даст возможность безболезненно дописать единую логику в зависимости от Не консоль/Консоль (пока что сделано как "не консоль").

Ну а дальше подумаю.
Либо 2 exe, либо "Консольное приложение" + FreeConsole на старте.

Патчить заголовок - однозначно дурной вариант. ЭЦП Code Signing имеется, в продакшн все подписывается, но причем тут это. От вирусовантивирусов кстати не всегда спасает. Но не об этом речь.

Здесь еще такой важный момент.
Кроме того что "Консольное" рисует черную консоль и чего-то туда пишет, оно еще берет управление на себя до своего завершения.
То которое "GUI" возвращает управление сразу.
Метод с AttachConsole не обеспечивает "корректной консоли" в случае cmd. Т.е. вроде как приаттачились и туда пишет, а управление уже передано в командную строку, даже "Press Any key..." не нажмешь.

К слову, "нормальный вариант" ("Консольное приложение" + FreeConsole на старте) кроме "мелькания консоли", еще и этим требованиям не удовлетворяет. Управление не будет передано в cmd сразу после FreeConsole, консоль будет ждать полного завершения "всех GUI".

Метод с AttachConsole обеспечит невозврат управления ("корректную консоль"),
если его из cmd запускать
start /w proga.exe

Теоретически можно написать маленькую "прокладку" на VB6, где требуемый функционал случайно или нарочно поддерживается.
Прокладка будет играть роль "start /w".
Т.е. если у меня нет ключа /Console, VB6 просто запускает .Net-exe и выходит
Если у меня ключ /Console, то VB6 делает AllocConsole (случайно или нарочно это в VB6 будет работать как грамотный AttachConsole без возврата управления в cmd), запускает .Net-exe которое делает AttachConsole к родительскому VB6 процессу. Но, при этом VB6-прокладка надо думать должна быть запущена до окончания работы .Net-exe (бесконечный цикл с DoEvents с проверкой завершился ли .Net-exe ? Псевдозагрузка процессора из-за цикла уже не есть good).
Ну, естественно, такой вариант не может сильно нравится, хотя он и обеспечит видимость и функциональность требуемого.

Дмитрий77Теоретически можно написать маленькую "прокладку" на VB6, где требуемый функционал случайно или нарочно поддерживается.
случайно или нарочно это в VB6 будет работать как грамотный AttachConsole без возврата управления в cmd
Короче не получится, соврал, забыл, ничего там такого нет и не было и все то же самое.

В VB6 у меня был грубо такой код:


При написании/тестировании это было НЕ консольное приложение, но наличие AllocConsole позволяло тестировать его как консольное на этапе написания.
А под конец делалось вот это:


Что превращало его в то что в .Net называется тип проекта="Консольное приложение" (в VB6 в проекте это задать нельзя).
После патча AllocConsole/FreeConsole теряют смысл, хотя и не мешают.
И да, был ключ /NoConsole, но он просто отменял вывод в консоль всякой всячины, но даже не закрывал саму консоль и тем более не менял тип приложения.

Исходя из того что хочу сейчас, получается ДА, только 2 exe-шника
1) "WinForm"+Main = а)нету консоли б) GUI в) возврат управления сразу
2) "Консольное приложение"= а)консоль б) вывод в консоль в) возврат управления по завершению

Код естественно единый.
(2) делается из (1) тупо либо сменой типа проекта, либо тем же LINK.exe (что одно и то же).