I was curious to see if it was possible to host PowerShell and PowerShell.exe in a similar fashion to the Java and Ruby setups detailed above. I think I’m missing a few things, or maybe I’ve just missed the boat completely. Either is fine. I was curious and was wondering if anyone else has investigated HttpPlatformHandler and its potential for PowerShell.
What I was trying to investigate and hopefully take advantage of was the IIS process management. Much like ASP.net apps in IIS if an app goes bad or crashes IIS restarts the process. I was looking to get this functionality for PowerShell scripts that use and consume events. Events are great, but only useful as long as the process is running. Close ISE or the PowerShell host and no more event actions. The script and web.config that I have been testing with are below. I’m not trying to solve a production problem, and I’m aware of the many other ways to deal with events. I’m investigating a new thing and if you have any thoughts please let me know what you think?
Well, for one, PowerShell is already a .NET class. Any ASP.NET page can “host” PowerShell, and IIS already natively “hosts” ASP.NET. So, technically… this has always been the case.
You wouldn’t host PowerShell.exe. PowerShell.exe isn’t “PowerShell,” it’s the console application. There’d be no need to host that in a web page, as there’d be no way to interact with it.
If the question is, “is there a way to make IIS run .ps1 script files as if they were Web pages” I guess my answer would be… you probably don’t want to do that. Certainly not with PowerShell.exe - that’d be a terrible idea. Just, ew. The “right” way would be to have an ASP.NET page summon up the PowerShell engine and then run whatever you wanted.
I think the distinction here is that PowerShell (the engine) is meant to be hosted by some kind of application. PowerShell.exe would just be a bad one to use in the context of a web server, what with concurrency and whatnot. You almost want a stripped-down host, like WsManProvHost.exe (used to host PowerShell as a Remoting target), to host PowerShell for use under IIS. I’m not aware of anyone who’s made one, though.
That host is necessary to instantiate the PowerShell engine, and to deal with accepting input and doing something with the output - like feeding it to IIS as a response stream or something. You’d probably want it to do something clever with the Error, Verbose, Debug, and Warning streams, too.
I’m not saying you couldn’t do this with PowerShell.exe. I’m suggesting you wouldn’t want to.
BTW… I think you’re a bit off-base WRT IIS “process management.”
ASP.NET doesn’t run as a “process.” The process is an IIS worker process; inside that worker process, whatever code needs to be run to handle a given request, is run. A single worker process could easily be running requests in ASP.NET, PHP, or anything else. Remember that a worker process comes from an app pool, and multiple websites can share that same app pool (and therefore, share the same worker process).
But it’s not like ASP.NET is sitting there running like a service. Keep in mind that IIS spins down workers that are idle, and recycles them periodically even if they haven’t crashed. The point of the process is to respond to a request, not to hang out doing useful work all the time. Code inside a worker process couldn’t be a permanent event subscriber.
What you’re actually describing - permanently-running code that can hook and respond to events over the long haul - is called a service. I’m not sure how performant it would be to run PowerShell.exe as a service; I suspect, like VBScript before it, it’d be poor, as the console host just wasn’t written with that in mind. However, it’d be fairly trivial to write a PowerShell custom host (in .NET) that was, in fact, designed to run as a service. Then you could have a runspace running “all the time” to hook and respond to events.
That doesn’t necessarily mean it’d auto-restart on a crash, but you could certainly write a host that was capable of monitoring its runspace, killing it in the event of an error, and re-starting one. Less trivial programming, perhaps, but it’s possible.