I got the following query in one of my Google hits today: "pipeline.Invoke() "Read-Host" Cannot invoke this function because the current host does not implement it."

I believe that this query was in reference to the lack of host functionality in the default settings for a runspace in Windows Powershell. I don't recall ever actually taking much about this, yet I am known for having abstracted the runspace API for use as a multi threading interface in Powershell. Now is a good time to talk some about this.

A runspace in Powershell is a big blob of information that pertains to a particular shell within Powershell. The runspace has several components within it, such as the cmdlets, aliases, functions, providers, etc. The host component specificly is ment to be used as an abstract interface to the console. The default host object used by a runspace doesn't have much functionality, so you may encounter error messages like the one above when you are using a generic host object.

It is possible to tell Powershell what host object should be used when the runspace is initialized. I do know that version 1.0 of powershell.exe will use a host that writes to the console used by the powershell.exe process. Since most other instances of Powershell don't have a console the host object will often be the default host object, that doesn't provide any functionality on its own, or a very simple host object, using only implementing a few methods in the PSHostUserInterface class.

From the query above it looks like this googler was trying to use Read-Host within an asynchronous runspace. The easy solution to this is to just not do so. It's easier, in most cases, to simply pass the needed information into the asynchronous runspace from the parent runspace. However, there are still some cases where you must use Read-Host from an asynchronous runspace. In that case you'll have to code and compile your own host class, and use that when initializing the runspace.