PowerShell and the new HttpPlatformHandler?

This topic contains 2 replies, has 2 voices, and was last updated by  Don Jones 2 years, 6 months ago.

  • Author
  • #22442

    Joel Reed

    I've been reading about the new HttpPlatformHandler that the Azure team has released and is using to host Java and Ruby inside of IIS.

    For some context see, Announcement, http://azure.microsoft.com/blog/2015/02/04/announcing-the-release-of-the-httpplatformhandler-module-for-iis-8/
    and Scott Hanselman testing, http://www.hanselman.com/blog/AnnouncingRunningRubyOnRailsOnIIS8OrAnythingElseReallyWithTheNewHttpPlatformHandler.aspx

    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?

    The web.config and the ps1 file are attached.

  • #22549

    Don Jones

    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 [i]couldn't[/i] do this with PowerShell.exe. I'm suggesting you wouldn't want to.

  • #22551

    Don Jones

    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.

You must be logged in to reply to this topic.