How to structure a powershell script to respond to windows commands? This not a request to run a powershell script in a framework, such as VS service, NSSM, etc. But how to write a powershell script that can receive and respond to service control commands, like start, stop, status, etc. Installing a powershell script as a service is one thing, but the actual script handling the service control commands directly is the goal. Don’t want to use a wrapper or shim, want 100% powershell solution, using powershell cmdlets to install, remove service (doable) and have the actual script react as a service its self. NSSM, SRVANY, etc. just mask the service control commands, the powershell script under these shims or wrappers is just a endless loop, what has no clue that is running in a service context, want to solve this gap.
Jibun,
Welcome back to the forum. 
… long time no see.
I’m not sure if I got it right. If you’re not talking about command line parameters the script should be able to listen to an open port for incomming control commands!? I doubt that PowerShell is the proper tool for that kind of task. 
Well that is the question really, a typical Windows service is control by the ‘commands’ it receives. If I were to create a Windows service via say Visual Studio, that communication methodology is structured and specific to a Windows Service. With PowerShell scripts, this is often done with creating a PowerShell script that at its core is a simple loop, and the shim or wrapper that invokes it, responds to the actual Windows service directives. I desire to cut out the middle man if you will, and have the actual PowerShell script ‘catch’ or intercept the Windows service control communication. In Unix/Linux world this is straight forward, even with say Python or other scripting engines. But with PowerShell based on all the documentation I have seen, it is easier to create an service EXE in say C#, and then have PowerShell install said service EXE. It appears that no one, from what I have found thus far, as taken up the challenge of a 100% native PowerShell approach to a Windows service. True, such an effort may have to leverage some .NET or DLL integration but that is fine as long as such is done within PowerShell standards for such. Then I thought, maybe some has done this, so I turned to this forum asking if some in fact has attempted this type of thing. Thus my posted question.
The use case I have, does not need speed or extensive efficiency, but has the requirement to be as PowerShell native as possible. After all, PowerShell makes calling Windows APIs pretty straight forward and easy (cough) most of the time, so this challenge at least seems possible at this point. Would this project be used for a serious demanding Windows service, no, of course an EXE would be more likely. The one advantage that PowerShell based native service would be it that it would be easy to understand and maintain since the core knowledge required is PowerShell alone, with some limited but expected DLL/.NET dependencies specific to Windows service control, i.e. stopped, started, restarted, etc. type of thing. just as any service is controlled.