Re: Getting logged in user from a service?

The purpose of the Framework is to virtualize the underlying OS services
and the HW, for instance by providing a layer in top of Win32, so you
better stay away from calling Win32 API's through PInvoke if you can
achieve the same (or better) when using the Framework classes.

That said, when the service restarts, you simply need to query whether the
process is already running using the System.Diagnostics.Process class or
the System.Management classes , get it's PID and pass it to something like
the "GetOwner" (using WMI Win32_Process class) I posted in my previous
reply.

He's dealing with Windows constructs here (services, WMI etc) which either
have no (compatible) analogue outside the Windows world or whose support
and/or availability is questionable (assuming he's even targetting such
environments which is highly unlikely). Pedantic arguments about a virtual
environment therefore don't apply IMO. Arguments about ease-of-use do apply
however so on that we agree. P/Invoke is complicated and error-prone so
should generally be avoided where possible. However, a service is inherently
low-level and shouldn't be relying on .NET in the first place IMO. Even WMI
is questionable here. While supported in .NET, a service should usually be
light-weight with few dependencies. This is much better accomplished by
relying on native OS functionality. Unfortunately, in the real world you
require very experienced (and more expensive) C++/ WinAPI developers to
write and support this. It's not viable in many shops and these types of
developers are also becoming an endangered species (I'm one of them). Your
points are therefore well taken.


.

Loading