Host should free the console for shared-framework app that sets subsystem = windows

[ericstj]

Similar to https://github.com/dotnet/core-setup/issues/4314. Related https://github.com/dotnet/core-setup/issues/196.

In the case of a standalone app the host should be specialized so that it will never pop a console window as specified in dotnet/sdk#1899.

In the case of a portable app this cannot be avoided: the host doubles as a console application and the only way to hook the same console you're launched with is to be a console app. The host can, however, decide to free the console via FreeConsole, once it launches the app.

I'm proposing that the default should be to free the console if the app being run is a windowed app. We could either read this from the dll at runtime or commit it to something (like the deps) at build time.

We should consider a switch like -wait that overrides this behavior (similar to start /wait) for cases where folks need the console blocked.

/cc @JeremyKuhne

[steveharter]

Need to coordinate with https://github.com/dotnet/core-setup/issues/196

[jkotas]

Who would be the Windowed portable apps for - when we would recommend to use them?

The host can, however, decide to free the console via FreeConsole, once it launches the app.

Is this going to cause the console to flash on the screen?

[ericstj]

Is this going to cause the console to flash on the screen?

Only in the case it was launched with dotnet.exe. We already have dotnet.exe, which is already a commandline app, so we should think about what that does when launching a windowed portable app.

In the case the application does not launch with dotnet.exe but has its own host, then that host should be specialized appropriately for the app. It should have subsystem=windows and never flash a console. This is what I'm suggesting here: dotnet/sdk#1899

I suspect the folks who ship windowed portable apps would be the set of folks who ship AnyCPU desktop exe's today.

Whether or not we do this (free the console), if we think this type of app is important we should also ship another exe (eg: dotnet-win.exe) that sets subsystem=windows. That way folks can have a production scenario that doesn't unprofessionally flash a console, while not having to ship a specific EXE that commits them to a single architecture.

[jkotas]

host should be specialized appropriately for the app

I agree with this one. I think it should be the one to promote for the UI .NET Core 3 apps. It will work best out of the different options.

ship a specific EXE that commits them to a single architecture

Commiting to a single architecture is good for predictable execution environment. The AnyCPU apps (original default) in .NET Framework were a pit of failure. People got burned by them and the template defaults were changed to not be AnyCPU as result. It would be useful to get input from the PM team on how much energy we need to spend on making AnyCPU .NET Core 3.0 UI apps work well.

[sdmaclea]

@vitek-karas Is this fixed with the gui flag in the executable?

[vitek-karas]

Unfortunately no. This change only implements it for standalone host.

[jkotas]

I think we should address this by generating the .exe for Windows GUI apps by default as discussed in dotnet/sdk#1899 (comment), and close this issue as won't fix. We can always reconsider based on feedback in future.