Search Wiki:


Use an ordinary PowerShell console to access your application's objects (explicitly hosted in a PowerShell runspace) at runtime, including tab expansion and piping objects into and out of your application.


PowerShellTunnel, what is it and why is it..

While using PowerShell to construct and manipulate .NET objects, did you ever think that it would be pretty cool to be able to open a PowerShell console and connect to and directly access the objects of a running application (at least the objects it exposes)? (You can't do this with Remoting in PowerShell 2.0 where you can only open new remote consoles.)

For example you might want to do:

  1. Ad-hoc debugging, diagnostics, or monitoring.
  2. Change object properties or calling methods at runtime.
  3. Ad-hoc (or scripted) unit, system, or integrity tests on a live application.
  4. Simulate events and actions.
  5. Allow automation of your application without explicit interface contracts (ad-hoc or prototyping APIs).
  6. Perhaps even adding or changing functionality on-the-fly.
  7. ... probably many other things you might think of.

There is an existing PowerShell Remoting project which uses a remote service to which you connect to to create a PowerShell host that you talk to through your client connection. This isn't quite what what I was after and after hearing that PowerShell 2.0 was coming, decided to wait and see. So PowerShell 2.0 CTP is here and does have Remoting ability but this is also focused on the administrative desire to summon a PowerShell console on a remote host and control it from the client, but neither approach can connect to an existing application's embedded PowerShell runspace.

So, after some reading and playing, PowerShellTunnel was created. PowerShellTunnel is a single VS2005 solution containing:

  1. Server-side cmdlets allowing you to start a 'tunnel host' from a PowerShell console or runspace. A 'tunnel host' allows 'tunnels' (tunnel clients) to access your console/runspace.
  2. Client-side cmdlets allowing you to start a 'tunnel' (connection) from a PowerShell console or runspace to an existing tunnel host (local or remote) and send scripts to onvoke on the tunnel host console/runspace. This includes piping objects in and out.
  3. Tab-expansion 'works' on the client: pressing tab will return tab expansion results from the tunnel host's runspace. A gotcha (for now) is that as long as you have a 'current tunnel' selected, tab expansion always diverts to the current tunnel's host.
  4. An ordinary 'embeddable' PowerShell runspace class (hostable by any .NET app) where you explicitly specify what objects to expose (specifying which PowerShell variable names) and any tunnel hosts to host.
  5. An example of a console application with a few simple objects that you can use to connect to from an ordinary PowerShell console.

Note that:
  1. WCF is used to do all the legwork of the underlying connection, by default the code uses http. By using WCF we avoid having to code for transport options, security, and other issues as this should be all achievable through WCF.
  2. Serializable objects can be piped into and out of the tunnel.
  3. The cmdlets also allow an ordinary PowerShell console to act as a tunnel host. This is the easiest way to start playing with PowerShellTunnel: use one PowerShell console as the tunnel host and another as the tunnel client. Similarly an embedded runspace could start a tunnel to any tunnel host too.
  4. Any console or runspace can have multiple tunnel hosts and/or can have multiple tunnels open.

To make a long story short, review the PowerShellTunnel Quick Start to see if this suits you. Use the Issue Tracker for any bugs or suggestions.
Use the Discussions tab for questions, comments, ideas, or to share how you have used PowerShellTunnel.

-Matthew Hobbs
(Very) Intermittent Blog
Last edited Jun 15 2009 at 2:00 AM  by MatHobbs, version 28
Page view tracker