Should we revise implementation of Environment.UserInteractive?

[MichalStrehovsky]

This is currently implemented as return true; but since in 3.0 we're adding UI stacks to .NET Core, maybe we should implement this since this is usually used before popping a UI?

The Windows version of the algorithm is copied all over the place (touching it in dotnet/corefx#39285, dotnet/winforms#1247).

[joperezr]

cc: @bartonjs

chatted offline with @ericstj and @JeremyKuhne about this. Seems like hard-coding the return to true is wrong, but I'm not sure if fixing this meets the bar for 3.0. There would have to be some other considerations in order to take the fix, for example, will perf be impacted in a meaningful way if we start PInvoking here? @MichalStrehovsky is there customer feedback prompting the fix for this? Or was this just discovered because you were touching the PInvoke and figured that we were also using it for this API in desktop?

[bartonjs]

It's 10% of applications in API port telemetry. Assuming that the scenario is "I'm about to pop a dialog, but if there's not actually a user attached I need to not" I'd say it meets the "we have UI stacks now" scenario blocking bar.

[jkotas]

Note that this is API tends to be used incorrectly, e.g. this is link on the first github page: https://github.com/mariusvrstr/SampleWeb/blob/e39bd73eccb110d1c83960188b9bd4d7bf4791af/Spike.Instrumentation/CustomLoggers/ServiceLogging.cs#L11

"fixing this" has potential to break things about as much as it fix them, e.g. it would change where the stuff gets logged in the example above. And there is easy workaround: Use the equivalent property from the UI stacks: https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.systeminformation.userinteractive

Given that we did not get any feedback about this property, I would be voting for keeping it as is.

[bartonjs]

And there is easy workaround: Use the equivalent property from the UI stacks

In that case, I'm inclined to agree (since it's a better place to ask).

[MichalStrehovsky]

@MichalStrehovsky is there customer feedback prompting the fix for this? Or was this just discovered because you were touching the PInvoke and figured that we were also using it for this API in desktop?

I noticed it by accident with findstr in the CoreFX codebase and realized we added it as a dummy in 2.0 and likely didn't revise since. I don't have a strong business case for fixing it and would be okay with Won't fix.

[joperezr]

Given the above discussion, I'd say that it doesn't meet the bar for 3.0 so moving it to future for now. We can discuss later if we want to fix this properly for a future release or if we just close it as won't fix.

[ericstj]

@jkotas that example would actually be fixed. UserInteractive returns false when the session doesn't have a display surface and thus logging to the console would never be seen. Today that example is losing all its logging.

Take the example:

using System;
namespace UserInteractive
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(Environment.UserInteractive);
        }
    }
}

Compile for desktop and run it directly, then run it from a service in the non-interactive session: psexec is handy for this.

EG: D:\scratch\UserInteractive>D:\scratch\UserInteractive\bin\Debug\net46\UserInteractive.exe
True

D:\scratch\UserInteractive>\tools\PsExec.exe \\ericstj-dev -s D:\scratch\UserInteractive\bin\Debug\net46\UserInteractive.exe

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


False
D:\scratch\UserInteractive\bin\Debug\net46\UserInteractive.exe exited on ericstj-dev with error code 0.

I don't disagree with moving to future until we have real feedback, but the fix should be straight-forward to restore the desktop behavior and it would largely still return true in the majority of cases, except when folks are running from services in non-interactive sessions. I think you're right that API is often misused to distinguish between GUI and console which is incorrect, but not something we should aim to change, but perhaps better document.

[gmatzen]

I am trying to convert my Full framework Windows service application to a dotnet core 3 windows service application. The application can run either as a service or interactively. Aside from logging, I need to know when it is appropriate to call ServiceBase.Run. I'm trying to figure out the best path forward because I was relying on Environment.IsUserInteractive for the full framework application.

[gfoidl]

@gmatzen: Aside from this topic, is .NET Core Workers as Windows Services an option for you?
When not run as service, it runs a plain console-app.

[gmatzen]

I am actually not sure if I can use the .net Core Workers as Windows Services option. For converting an existing service, it is mostly straightforward to use the Microsoft.Windows.Compatibility nuget package. The biggest problem I ran into was the misbehaving Environment.UserInteractive. In the .NET Core Workers as Windows Services example in the link that you provided, it is not obvious what the code path for a non-service would be. The example states that the non-service is a no op, but it is quite useful to run the same code as a console application for troubleshooting purposes, using a console logger instead of the event log. Since our application is currently released, I would prefer the existing behavior to be as similar to the previous behaviors as possible.

[gfoidl]

the non-service is a no op, but it is quite useful to run the same code as a console application

It will run as console app when not run as windows-service. Just as you expect. You can debug, etc.
But let's not hijack this issue therefore.

[SteveL-MSFT]

Apparently PowerShell scripts are relying on this to determine if their scripts are running on an interactive winstation, for example detecting if their script is run via task scheduler.