PowerShellTunnel - script your app from PowerShell at runtime

UPDATED WIKI: PowerShellTunnel Known Issues

MatHobbs — Mon, 15 Jun 2009 02:04:13 GMT

PowerShellTunnel - Known Issues

1) Updating a UI control on the hosting application from a tunnelled command - hangs. note that tunnel commands are executed on a non-UI thread so I had a go at ensuring that the update of the Ui control was done using Invoke or BeginInvoke but still got the hang. it seems that being in the pipeline Invoke stops the UI control Invoke from doing anything?

UPDATED WIKI: PowerShellTunnel Known Issues

MatHobbs — Mon, 15 Jun 2009 02:02:45 GMT

UPDATED WIKI: Home

MatHobbs — Mon, 15 Jun 2009 02:00:24 GMT

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.

Home - where you are now.
PowerShellTunnel Quick Start - a quick step-by-step walk-through of PowerShellTunnel.
PowerShellTunnel How to Install - a guide to requirements and installing PowerShellTunnel.
PowerShellTunnel How to Uninstall - a guide to uninstalling PowerShellTunnel.
PowerShellTunnel How to Build - a guide to building PowerShellTunnel.
PowerShellTunnel Reference - a guide to the cmdlets and PowerShellTunnel.sln.
PowerShellTunnel Considerations - notes on various issues relating to PowerShellTunnel.
PowerShellTunnel Known Issues - known issues using PowerShellTunnel.

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:

Ad-hoc debugging, diagnostics, or monitoring.
Change object properties or calling methods at runtime.
Ad-hoc (or scripted) unit, system, or integrity tests on a live application.
Simulate events and actions.
Allow automation of your application without explicit interface contracts (ad-hoc or prototyping APIs).
Perhaps even adding or changing functionality on-the-fly.
... 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:

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.
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.
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.
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.
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:

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.
Serializable objects can be piped into and out of the tunnel.
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.
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.

Cheers,
-Matthew Hobbs
(Very) Intermittent Blog

NEW POST: Working around the serialization issue

MatHobbs — Thu, 06 Nov 2008 08:59:02 GMT

Hi Phil,

I haven't seen this or looked into that at all. Fortunately, I've only had to deal with serializable objects when I've needed to actually bring the object up or down the tunnel. I wonder if for other objects this clixml mechanism could be used to implement a proxy to 'wrap' an object living only at the other end of the tunnel (so the proxy would encapsulate the tunnel itself), or just use as a way to create local PSObjects with imitation properties for local use (with access only to data and not methods)...

By now I was kind of hoping that the upcoming PowerShell 2.0 would have made this project obsolete but still there is no apparent way to connect to an existing runspace (e.g. hosted by an app, remote or otherwise) - perhaps 3.0?

Cheers,
-Mat

NEW POST: Working around the serialization issue

Phil_Bolduc — Tue, 21 Oct 2008 08:25:28 GMT

I was wondering if you could use export-clixml & import-clixml cmdlets to get around the issue of a type that could not be serialized. The side effect is that you will need to write and then read from the file system. Scott Hanselman's article on ScriptBlock and Runspace Remoting in PowerShell discusses it use. http://www.hanselman.com/blog/ScriptBlockAndRunspaceRemotingInPowerShell.aspx. I was wondering if you had considered using it.

UPDATED WIKI: PowerShellTunnel Considerations

MatHobbs — Thu, 03 Apr 2008 07:56:27 GMT

PowerShellTunnel - Considerations

A) If you don't want to connect to an existing embedded runspace but instead want to remote-connect to new PowerShell 'consoles' on remote clients, refer instead to PowerShell 2.0 or the "PowerShell Remoting" project. PowerShellTunnel is designed for connecting to an existing console or runspace.

B) The PowerTab project could make tab expansion integration cleaner.

C) Serialization: PowerShellTunnel uses ordinary serialization by serialized pipied input or output objects to a stream and sending a raw byte array to and from the tunnel host. If the class is not serializable then just the type name will be sent. PowerShellTunnel does not use WCF data contract serialization for the piped objects themselves.

D) TODO: Add 'help', 'verbose', functionality to cmdlets.

E) Security Warning: once connected to the tunnel host, the tunnel has access to all of the tunnel host's exposed objects and functionality (c.f. Skynet). (Future Powershell runspaces may be restrictable to limit what objects can be accessed.)

F) Multiple hosts/clients: You can create multiple tunnel hosts and multiple tunnels, e.g. a host may be accessed by multiple clients. A client may use multiple tunnels (to different hosts) and use: "select-tunnel" to switch between them or use the "-tunnel" parameter of "invoke-tunnel".

G) Threading: Be aware of threading considerations given that the tunnel host executes on a WCF worker thread (e.g. on a .NET Thread Pool thread).

H) No Ctrl-C? If you invoke-tunnel a script, Ctrl-C from the client does not interrupt it, so beware of infinite loops or long operations.

I) After 'select-tunnel' (or add-tunnel without the -noselect switch), tab expansion is intercepted to to tab expansion on the tunnel host. This is useful when typing the script block of the invoke-tunnel but not especially elsewhere. Use select-tunnel without a parameter to turn off the tab expansion interception (and requires invoke-tunnel to specify a '-tunnel xyz' parameter).

J) There might be ways to streamline the user syntax/experience further. In the meanwhile, consider using an alias to Invoke-Tunnel, e.g.
Set-Alias T Invoke-Tunnel
Set-Alias TP Invoke-Tunnel -pipeoutput
or
function T1 { Invoke-Tunnel -tunnel $mytunnel1 $args}

CREATED ISSUE: Increase WCF Default Message Size Limits

MatHobbs — Wed, 19 Mar 2008 06:16:40 GMT

The default WCF mssage receive size limit of 65536 bytes can be easily hit. Increase this to 1000000000 bytes by default. Also increase WCF data contract serializer setting MaxItemsInObjectGraph and set PreserveReferences to true.

NEW POST: Using invoke-tunnel on XP SP2

MatHobbs — Wed, 19 Mar 2008 06:13:47 GMT

Hi Marco, ah yes: WCF's default limits. Your $x probably referenced an object that would be serialized to > 65536 bytes. I uploaded a new PowerShellTunnel release ("1.01") that bumps up two important WCF settings so you should not get this any more unless your objects is > 1000000000 bytes!

Cheers,
-Mat

CREATED RELEASE: PowerShellTunnel v1.01 Source (Mar 18, 2008)

Wed, 19 Mar 2008 06:09:02 GMT

Additions only for the default WCF behavior:
1) Increase the default MaxReceivedMessageSize so large objects can be serialized and piped without a WCF error.
2) Add a custom data contract serializer behavior to increase MaxItemsInObjectGraph too.

UPDATED WIKI: PowerShellTunnel Quick Start

MatHobbs — Wed, 19 Mar 2008 06:00:05 GMT

PowerShellTunnel - Quick Start

With PowerShellTunnel you create a tunnel between two endpoints: the tunnel 'host' and the tunnel 'client' - you need to start both. You send scripts from the client to execute on the host as if you had typed them directly into the host (including tab expansion), so you have access to all the objects and capabilities of the host from the client. Objects can be piped into or out of the tunnel (ordinary serialization is used).

If you want to follow through the quick start, you'll need to first go through PowerShellTunnel How to Build and PowerShellTunnel How to Install.

This quick-start works through two scenarios:

Console -> Console: Two PowerShell consoles, one acts as a tunnel host, the other as a tunnel client.
Console -> Application: One ordinary .NET console application with an embedded PowerShell runspace (which exposes some application objects as ordinary PowerShell variables) which hosts a tunnel, and an ordinary PowerShell console which acts as a tunnel client to interact with the application's objects while the application is running.

Console -> Console

In this scenario, the tunnel host will be a PowerShell console with a couple of objects which we will try to access from another PowerShell console (the tunnel client).

Step 1) Create the Tunnel Host.

1-a) Start a PowerShell console.

1-b) Enter the following commands to add the snapin, add a tunnel host (use the address you specified when you did the install, or refer to PowerShellTunnel How to Install to add an http permission for your user if necessary), and create a couple of ordinary objects:

add-pssnapin PowerShellTunnel
$tunnelhost = add-tunnelhost "http://localhost:8000/PowerShellTunnel/Host1"
$x = dir
$y = $x[0]

Step 2) Create the Tunnel Client.

2-a) Start a PowerShell console.

2-b) Enter the following commands to add the snapin and add a tunnel to the tunnel host (using the same address that you used for the host).

add-pssnapin PowerShellTunnel
$tunnel = add-tunnel "http://localhost:8000/PowerShellTunnel/Host1"

2-c) Access the objects on the host. Note that tab expansion works correctly, e.g. on the Name property of $y, i.e. $y.N{TAB} becomes $y.Name. The pipeline should work (both in and out) so long as types are WCF-OK (standard types or types made known to WCF ...).

Examples:

invoke-tunnel { $x }
invoke-tunnel { $y.Name }
$yLocal = invoke-tunnel { $y }; $yLocal # $yLocal is set to a local (serialized & deserialized) copy of $y
invoke-tunnel { $z = "This variable is set on the host!" }

Example piping objects in and out:

"write line #1", "write line #2", ("write", "line", "#3" ) | invoke-tunnel { $input | foreach { write-host $_; "$_".Length } }
$myx = invoke-tunnel { $x } -pipe    #sets $myx to a list of DirectoryInfo and FileInfo objects piped from the host

Example sending a script file:

'$z = 4; $z = $z*$z; write-host "On Host: $z"; "Return to client: $z" ' > test.ps1
type test.ps1 | invoke-tunnel { invoke-expression $input }
del test.ps1

Note: if there are multiple tunnels, then select-tunnel can be used to change the current invoke-tunnel default (and redirect tab expansion), or invoke-tunnel can be called with a '-tunnel xyz' parameter.

Step 3) Switch back to the host console and verify that you see:

write line #1
write line #2
write line #3

and verify that $z was created:

$z  #You'll see "This variable is set on the host!"

Step 4) Switch back to the client console and remove (close) the Tunnel and remove the snapin.

Remove-Tunnel $tunnel
Remove-PSSnapin PowerShellTunnel

Step 5) Switch back to the host console and remove (close) the Tunnel Host and remove the snapin.

Remove-TunnelHost $tunnelhost
Remove-PSSnapin PowerShellTunnel

Console -> Application

In this scenario, the tunnel host will be a PowerShell runspace hosted (embedded) within a console application (PowerShellTunnel.Embeddable.Example.exe) which 'exposes' a few of its objects as PowerShell variables in the hosted runspace. The client will be an ordinary PowerShell console as before.

Step 1) Create the Tunnel Host.

First, if you are re-using the same host address from before, close the tunnel host console from the 'Console -> Console' walkthrough if it is still open.

Build and run PowerShellTunnel.Embeddable.Example.exe. This is a console application that outputs some information and waits on a Console.Readline() where pressing Enter exits the application. A PowerShell runspace is hosted and a tunnel host created in the runspace at address "http://localhost:8000/PowerShellTunnel/Host1" (or change this value in program.cs).

Step 2) Create the Tunnel Client.

2-a) Start a PowerShell console.

2-b) Enter the following commands to add the snapin, add a tunnel to connect to the above tunnel host (using the address that you used for the host).

add-pssnapin PowerShellTunnel
$tunnel = add-tunnel "http://localhost:8000/PowerShellTunnel/Host1"

2-c) Access the objects on the host. Note that tab expansion works correctly, e.g. on the Name property of $y, i.e. $y.N<TAB> becomes $y.Name. The pipeline should work (both in and out) so long as the piped types are serializable.

invoke-tunnel { $myvar1 }
invoke-tunnel { $myvar2 }
invoke-tunnel { $myvar3 }

The same kinds of access is available as before with some warnings:

The example hosted runspace does not have a console so any scripts which access the console in any way will fail (you can create a more advanced host).
The tunnel host gets its requests on WCF worker threads, so be aware of multi-threading issues on whatever is exposed via the runspace.
Be aware that the client has access to anything that the hosted runspace has.
You may want to configure WCF security in the general case.

General Notes

Refer to PowerShellTunnel Considerations.

EDITED ISSUE: Increase WCF Default Message Size Limits

MatHobbs — Wed, 19 Mar 2008 03:17:32 GMT

NEW POST: Using invoke-tunnel on XP SP2

marcoshaw — Fri, 14 Mar 2008 20:28:56 GMT

Following your guides:

PSH> invoke-tunnel { $x }
Invoke-Tunnel : The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota,
use the MaxReceivedMessageSize property on the appropriate binding element.
At line:1 char:14
+ invoke-tunnel <<<< { $x }

Still appears things are working.

UPDATED WIKI: Home

MatHobbs — Thu, 13 Mar 2008 05:34:31 GMT

PowerShellTunnel

Host a PowerShell runspace and expose application objects as ordinary PowerShell variables. Add a 'tunnel host', then use an ordinary (local or remote) PowerShell console (or runspace) to 'tunnel' (connect using WCF) to your application's runspace at runtime and script away.

Home - where you are now.
PowerShellTunnel Quick Start - a quick step-by-step walk-through of PowerShellTunnel.
PowerShellTunnel How to Install - a guide to requirements and installing PowerShellTunnel.
PowerShellTunnel How to Uninstall - a guide to uninstalling PowerShellTunnel.
PowerShellTunnel How to Build - a guide to building PowerShellTunnel.
PowerShellTunnel Reference - a guide to the cmdlets and PowerShellTunnel.sln.
PowerShellTunnel Considerations - notes on various issues relating to PowerShellTunnel.

PowerShellTunnel, what is it and why is it..

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

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.
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.
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.
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.
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:

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.
Serializable objects can be piped into and out of the tunnel.
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.
Any console or runspace can have multiple tunnel hosts and/or can have multiple tunnels open.

UPDATED RELEASE: PowerShellTunnel v1.0 Source (Mar 02, 2008)

Mon, 03 Mar 2008 07:34:18 GMT

First release (source only) including the source required to build the PowerShellTunnel assembly (PowerShellTunnel.dll) and an example application host (PowerShellTunnel.Embeddable.Example.exe).

RELEASED: PowerShellTunnel v1.0 Source (Mar 02, 2008)

Mon, 03 Mar 2008 07:34:18 GMT

First release (source only) including the source required to build the PowerShellTunnel assembly (PowerShellTunnel.dll) and an example application host (PowerShellTunnel.Embeddable.Example.exe).

UPDATED RELEASE: PowerShellTunnel - Initial Release (Source) (Mar 02, 2008)

Mon, 03 Mar 2008 07:32:41 GMT

Initial source-only release including the source required to build the PowerShellTunnel assembly (PowerShellTunnel.dll) and an example application host (PowerShellTunnel.Embeddable.Example.exe).

UPDATED RELEASE: PowerShellTunnel - Initial Release (Source) (Mar 02, 2008)

Mon, 03 Mar 2008 07:31:24 GMT

Initial source-only release including the PowerShellTunnel assembly (PowerShellTunnel.dll) and an example application host (PowerShellTunnel.Embeddable.Example.exe).

CREATED RELEASE: PowerShellTunnel - Initial Release (Source) (Mar 02, 2008)

Mon, 03 Mar 2008 07:29:10 GMT

Initial source-only release including the PowerShellTunnel assembly (PowerShellTunnel.dll) and an example application host (PowerShellTunnel.Embeddable.Example.exe).

UPDATED WIKI: PowerShellTunnel Considerations

MatHobbs — Mon, 03 Mar 2008 07:13:25 GMT

PowerShellTunnel - Considerations

A) If you don't want to connect to an existing embedded runspace but instead want to remote-connect to new PowerShell 'consoles' on remote clients, refer instead to PowerShell 2.0 or the "PowerShell Remoting" project. PowerShellTunnel is designed for connecting to an existing console or runspace.

B) The PowerTab project could make tab expansion integration cleaner.

C) Serialization: PowerShellTunnel uses ordinary serialization by serialized pipied input or output objects to a stream and sending a raw byte array to and from the tunnel host. If the class is not serializable then just the type name will be sent. PowerShellTunnel does not use WCF data contract serialization for the piped objects themselves.

D) TODO: Add 'help', 'verbose', functionality to cmdlets.

E) Security Warning: once connected to the tunnel host, the tunnel has access to all of the tunnel hosts exposed objects and functionality.

F) Multiple hosts/clients: You can create multiple tunnel hosts and multiple tunnels, e.g. a host may be accessed by multiple clients. A client may use multiple tunnels (to different hosts) and use: "select-tunnel" to switch between them or use the "-tunnel" parameter of "invoke-tunnel".

G) Threading: Be aware of threading considerations given that the tunnel host executes on a WCF worker thread (e.g. on a .NET Thread Pool thread).

H) No Ctrl-C? If you invoke-tunnel a script, Ctrl-C from the client does not interrupt it, so beware of infinite loops or long operations.

I) After 'select-tunnel' (or add-tunnel without the -noselect switch), tab expansion is intercepted to to tab expansion on the tunnel host. This is useful when typing the script block of the invoke-tunnel but not especially elsewhere. Use select-tunnel without a parameter to turn off the tab expansion interception (and requires invoke-tunnel to specify a '-tunnel xyz' parameter).

J) There might be ways to streamline the user syntax/experience further. In the meanwhile, consider using an alias to Invoke-Tunnel, e.g.
Set-Alias T Invoke-Tunnel
Set-Alias TP Invoke-Tunnel -pipeoutput
or
function T1 { Invoke-Tunnel -tunnel $mytunnel1 $args}

UPDATED WIKI: PowerShellTunnel Considerations

MatHobbs — Mon, 03 Mar 2008 07:10:50 GMT

PowerShellTunnel - Considerations

A) If you don't want to connect to an existing embedded runspace but instead want to remote-connect to new PowerShell 'consoles' on remote clients, refer instead to PowerShell 2.0 or the "PowerShell Remoting" project. PowerShellTunnel is designed for connecting to an existing console or runspace.

B) The PowerTab project could make tab expansion integration cleaner.

C) Serialization: PowerShellTunnel uses ordinary serialization by serialized pipied input or output objects to a stream and sending a raw byte array to and from the tunnel host. If the class is not serializable then just the type name will be sent. PowerShellTunnel does not use WCF data contract serialization for the piped objects themselves.

D) TODO: Add 'help', 'verbose', functionality to cmdlets.

E) Security Warning: once connected to the tunnel host, the tunnel has access to all of the tunnel hosts exposed objects and functionality.

F) Multiple hosts/clients: You can create multiple tunnel hosts and multiple tunnels, e.g. a host may be accessed by multiple clients. A client may use multiple tunnels (to different hosts) and use: "select-tunnel" to switch between them or use the "-tunnel" parameter of "invoke-tunnel".

G) Threading: Be aware of threading considerations given that the tunnel host executes on a WCF worker thread (e.g. on a .NET Thread Pool thread).

H) No Ctrl-C? If you invoke-tunnel a script, Ctrl-C from the client does not interrupt it, so beware of infinite loops or long operations.

I) After 'select-tunnel' (or add-tunnel without the -noselect switch), tab expansion is intercepted to to tab expansion on the tunnel host. This is useful when typing the script block of the invoke-tunnel but not especially elsewhere. Use select-tunnel without a parameter to turn off the tab expansion interception (and requires invoke-tunnel to specify a '-tunnel xyz' parameter).

J) There might be ways to streamline the user syntax/experience further. In the meanwhile, consider using an alias to Invoke-Tunnel, e.g.
Set-Alias T Invoke-Tunnel
or
function T1 { Invoke-Tunnel -tunnel $mytunnel1 $args}

PowerShellTunnel - script your app from PowerShell at runtime

UPDATED WIKI: PowerShellTunnel Known Issues

PowerShellTunnel - Known Issues

UPDATED WIKI: PowerShellTunnel Known Issues

UPDATED WIKI: Home

PowerShellTunnel

Contents

PowerShellTunnel, what is it and why is it..

NEW POST: Working around the serialization issue

NEW POST: Working around the serialization issue

UPDATED WIKI: PowerShellTunnel Considerations

PowerShellTunnel - Considerations

CREATED ISSUE: Increase WCF Default Message Size Limits

NEW POST: Using invoke-tunnel on XP SP2

CREATED RELEASE: PowerShellTunnel v1.01 Source (Mar 18, 2008)

UPDATED WIKI: PowerShellTunnel Quick Start

PowerShellTunnel - Quick Start

Console -> Console

Step 1) Create the Tunnel Host.

Step 2) Create the Tunnel Client.

Step 3) Switch back to the host console and verify that you see:

Step 4) Switch back to the client console and remove (close) the Tunnel and remove the snapin.

Step 5) Switch back to the host console and remove (close) the Tunnel Host and remove the snapin.

Console -> Application

Step 1) Create the Tunnel Host.

Step 2) Create the Tunnel Client.

General Notes

EDITED ISSUE: Increase WCF Default Message Size Limits

NEW POST: Using invoke-tunnel on XP SP2

UPDATED WIKI: Home

PowerShellTunnel

Contents

PowerShellTunnel, what is it and why is it..

UPDATED RELEASE: PowerShellTunnel v1.0 Source (Mar 02, 2008)

RELEASED: PowerShellTunnel v1.0 Source (Mar 02, 2008)

UPDATED RELEASE: PowerShellTunnel - Initial Release (Source) (Mar 02, 2008)

UPDATED RELEASE: PowerShellTunnel - Initial Release (Source) (Mar 02, 2008)

CREATED RELEASE: PowerShellTunnel - Initial Release (Source) (Mar 02, 2008)

UPDATED WIKI: PowerShellTunnel Considerations

PowerShellTunnel - Considerations

UPDATED WIKI: PowerShellTunnel Considerations

PowerShellTunnel - Considerations