Search Wiki:

PowerShellTunnel


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.

Contents



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 darn 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)?!

Some things you might do:

  1. Ad-hoc debugging, diagnostics, or monitoring.
  2. Changing object properties or calling methods at runtime.
  3. Ad-hoc (or scripted) unit, system, or integrity tests on a live application.
  4. Simulating events and actions.
  5. Perhaps even adding or changing functionality on-the-fly.
  6. ... 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, I had a go and came up with PowerShellTunnel, a project which contains:

  1. Server-side cmdlets allowing you to start a 'tunnel host' from a PowerShell console (or any PowerShell 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 the tunnel host console or runspace.
  3. Tab-expansion 'works' in that while typing a script destined for a tunnel host, 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 divert 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 (and choosing which PowerShell variable names) and what 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.
  6. 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 worry about transport options, security, and other issues as this should be all configurable.
  7. WCF-serializable objects can be piped into and out of the tunnel (types unknown to WCF DataContractSerializer need to be registered as known types).
  8. The cmdlets also allow an ordinary PowerShell console to act as a tunnel host (the easiest way to start playing with PowerShellTunnel is to use one PowerShell console as the host and another as the client). Similarly an embedded runspace could start a tunnel to any tunnel host too.
  9. Any console or runspace can have multiple tunnel hosts and/or can have multiple tunnels open.
  10. There is a single PowerShellTunnel.sln (VS2005), within in there is a Docs solution folder with a readme.txt to get you started on working through some examples.

To make a long story short, review the PowerShellTunnel Quick Start and if it suits you, try it out!

Let me know if there is similar technology out there or if PowerShell 2.0's Remoting can be adapted to this end (but from what I read it cannot - for example it only connects to sessions spawned from that same console which may be remote, but which are not pre-existing or embedded). Also please use the Issue Tracker for any bugs or suggestions or the Discussions tab for questions, comments, ideas, or any ways you have used PowerShellTunnel or other similar approaches.

Cheers,
-Matthew Hobbs
Intermittent blog
Email



**Delete the following note before publishing **

This resource page is currently in setup mode and only available to coordinators and developers. Once you have finished setting up your resource page you can publish it to make it available to all MSDN Code Gallery visitors.

To get your Resource Page ready to publish, you should do the following:
  1. Make any changes to the details of your resource page
    1. Here you can enable or disable functions of your resource page. You might want to turn on the Issue Tracker to allow users to provide feedback on your resource, or if you have a resource that does not involve a code sample, you may want to turn off the Releases tab.
    2. Make sure your resource page description is detailed enough to let people search for your resource.
  2. Add your code sample or other resources to the resource page
    1. If you’re uploading code, go to the Releases tab and create a new release to house your code. Creating a release allows you to have the license properly displayed when people download your code, as well as provides a download count.
    2. Edit your Wiki page to attach any resources you may have that are not source code.
  3. If you want to let someone see your resource page before it is published, go to the People tab and add them to your resource page
    1. This will let you add other team members who may be contributing to your resource, or just show it off and get feedback from someone you trust.
  4. Tag your resource page with descriptive tags to make it easier for people to find your resources when browsing the gallery.
  5. Publish your resource page so it becomes visible to everyone!

Additional information on starting a new resource page is available here: Resource Page Startup Guide.
Last edited Feb 14 2008 at 7:53 AM  by MatHobbs, version 7
Updating...
Page view tracker