Check `Environment.UserInteractive` before showing UI

It doesn’t seem to affect WinForms. The checks come from WPF itself.

Perhaps winforms should add these checks 😄 - no point in trying to show ux when Environment.UserInteractive is (genuinely) false.

_Originally posted by @vatsan-madhavan in https://github.com/dotnet/wpf/issues/2663#issuecomment-592207176_

[danmoseley]

Happened to notice this. The proposal would not work since as written, both Winforms’ UserInteractive impl and the core libraries will return “true” (ie interactive) if GetUserObjectInformationW fails. It will fail on Windows Nano, and thus indicate interactive is true, and Nano certainly doesn’t support UI.

https://source.dot.net/#System.Windows.Forms/System/Windows/Forms/SystemInformation.cs,640 https://github.com/danmosemsft/runtime/blob/7a1ff8272bd8afe74ed1b98b8c7d1f6c6a6d2a07/src/libraries/System.Private.CoreLib/src/System/Environment.Windows.cs#L144

I don’t know about hte Winforms version, but the Environment API is essentially for code running on regular Windows SKU’s to determine whether they are running within a non-interactive Windows Service.

[weltkante]

Even though we repeatedly tell developers not to run WPF from within Windows services and that it’s unsupported

The problem is that the borders are fluent: COM - STA - HWND - UI are all interconnected - at which point do you make the cut to “unsupported” and at which point do you actually disallow a primitive when validating UserInteractive in WinForms? Unsupported only means you don’t get to ask for bugfixes, not that you aren’t allowed to do it, last time I heared about it VS puts the new style project system compiling against Desktop Framework under “unsupported” yet still large parts of the ecosystem rely on it to work.

they do so anyway; perhaps this happens in the WinForms ecosystem as well?

We have one service out of 20 or something that prints daily reports and requires WinForms to work. It already needs to be switched some flag to work in the first place, so it might be that for this service “UserInteractive” would evaluate to true anyways. I don’t know the details but I could check.

We don’t encourage the usage of that service, but there’s certainly demand in running UI code “offscreen” without a user logged on. Some customers want their daily reports printed and mailed automatically without having someone logged on permanently on the machine just so a process can run in UI context. The reporting library is winforms based and putting everything in a service is much easier than writing the interop required to allocate a window station and logon a dummy user via the win32 API (if thats even possible, I know there are APIs for things like this but never tried to do it, you’d basically writing your own service infrastructure with UI support).

Devs are usually trying to solve a problem, declaring a solution “unsupported” doesn’t matter, if its the “best” solution the devs can find they’ll take it anyways. If you want to avoid that, offer them alternatives to solve their problem, rather than declaring it unsupported.

In general, many common libraries are written with UI context in mind yet there is still occasional demand running them in an automated fashion without having a user sitting in front of a screen. So you usually have the choice on going unsupported or reinvent everything, of course almost nobody can afford to do the latter.

I’m mentioning all that just as a data point since it came up in the discussion, I personally still have no preference over whether winforms should be usable in service context or not.