Vista - Hosting PowerShell & passing parameters to script

I am hosting PowerShell in my application. There are number of scripts I want
to execute, some of them have arguments which can't be passed as a string.
For example:

param ([Exception]$e)

echo $e.Message

$MailMessage = New-Object -typename System.Net.Mail.MailMessage
$MailMessage.From = "somebody@xxxxxx"
$MailMessage.To.Add("somebody@xxxxxx")
$MailMessage.Subject = "Message from PowerShell"

$MailMessage.Body += $e.Message + "`n"
$MailMessage.Body += $e.CallStack

$smtp = New-Object -typename System.Net.Mail.SmtpClient
$smtp.Host = "domain.com"
$smtp.Port = 25
$smtp.Send($MailMessage)


It is a simple script but the point is: I want to pass objects to my script,
which can't be represented as string.

If I run this script from PowerShell console it works fine:
PS D:\> $e = New-Object -typename System.IO.FileNotFoundException -argument
"Test"
PS D:\> .\script.ps1 $e
Test

and email is sent. But when I try to run this script in my application
(through RunspaceInvoke or creating pipeline with command) it fails with:

The term 'param' is not recognized as a cmdlet, function, operable program,
or script file. Verify the term and try again.

And I have no idea why it happens.
Any thoughts?
Thanks.

On Sep 18, 7:26 am, Dmitry Naumov <Dmitry
Nau...@xxxxxx> wrote:I'm going to take an educated guess here, but this is probably going
to be fixed in v2. It looks related to the issue whereby you cannot
use "param" in ScriptMethods either, and are forced to use the
automatic variable $args instead. See:

http://groups.google.com/group/micro...17595f7c2cdecf

- Oisin

"Dmitry Naumov" <Dmitry Naumov@xxxxxx> wrote in message
news:1DC6ACB9-3EB6-4D51-861D-BB4960987205@xxxxxxCan you post more detail on how you're creating a pipeline with command? It
works for me when I create the command line this:

Pipeline pipe = runSpace.CreatePipeline();
Command cmd = new Command("C:\Script.ps1");
cmd.Parameters.Add("name", value);
pipe.Commands.Add(cmd);
pipe.Commands.Add("out-default");
pipe.Invoke();

"John Vottero" wrote:
John,
There is the difference between your sample and mine. You invoke script
located in file, I try to run script which is located in System.String.

On Sep 19, 1:46 am, Dmitry Naumov
<DmitryNau...@xxxxxx> wrote:Ahh, I misunderstood your original question. Hmm, if you're trying to
invoke that string in an interactive context, param will indeed be
invalid. You can verify this yourself by firing up powershell and
trying to run "param" as a command:

PS C:\> param
The term 'param' is not recognized as a cmdlet, function, operable
program, or script file. Verify the term and try again.
At line:1 char:5
+ param <<<<

If you don't invoke the script as a ps1 file, you won't get implicit
parameter support. It's hard to help you with this without seeing how
you are hosting the runtime.

- Oisin

"Oisin Grehan" wrote:
Actually nothing special in the hosting:

// runspace is created and opened somewhere before...
using (Pipeline pipeline = runspace.CreatePipeline())
{
Command command = new Command(myScript, true);
// Command command = new Command(pathToTempFileWithScript);
pipeline.Commands.Add(command);

foreach (WorkflowParameterBinding parameterBinding in parameterBindings)
{
command.Parameters.Add(parameterBinding.ParameterName,
parameterBinding.Value);
}

pipeline.Invoke();
}

It even works if I save my script to temporary file (commented line), but I
want the same functionality without saving to file.

On Sep 20, 1:56 am, Dmitry Naumov
<DmitryNau...@xxxxxx> wrote:Hi Dmitry,

A piece of script executed like this does not qualify to have
parameters - it needs be in an explicit "container," like a function,
or a ps1 script file. Parameter binding like this also works for
binding to native Cmdlets parameters. However...

I'll take an educated guess that you're trying to use a powershell as
a windows workflow activity. I suggest the best way to get this to
work in a friendly way is to dynamically wrap your activity script in
a function declaration, perhaps named after the activityID; this will
keep it unique in your runspace's function namespace (that I presume
you're keeping persistant throughout the workflow, if not, then I
guess that doesn't matter). First, create a Command object -- like
you're currently doing -- and specify that it is script, but wrap it
in a function declaration with named parameters, e.g.

string myScript = @"param([Exception]$ex); ... rest of script
here ...";
string wrappedScript = String.Format("function perform-activity_{0}
{ {1} }", activityID, myScript);


Execute this; next, create another pipeline and specify false to
indicate it's a command (not script) and specify the command text
(e.g. "perform-activity_25") as the name of your previously generated
function. You can now bind your workflow parameters to this command
and execute it.

Hope this gets you going in the right direction, and if you get it
working, I'm sure the group will appreciate some wwf/powershell code
like this ;-)

- Oisin

"Oisin Grehan" wrote:
Oisin,
thank you for great idea. I did some research in this direction (wrapping
script in function), but didn't catch idea that I need two different
pipelines. Thanks a lot.

Now it works perfectly: script parameters are visible in activity designer
as activity properties, their are even can be strong typed and available for
binding. The only thing I am concerned is that Runspace, which I am going to
add to WorkflowRuntime services, will be soiled with lot of "wrapped
scripts". Is there a way to clean up after script execution?

"Dmitry Naumov" wrote:

<snip>Hi Dmitry,

Glad it's worked out for you - yes, you can clean up by deleting the
function. Functions are stored on the "function" drive, and can be deleted
via remote-item like any other item on a powershell drive. e.g.

remove-item functionerform-activity_26

I think you know enough to work out the rest ;-)

- Oisin / x0n

--
@("PSEventing","PSSharePoint","PowerShellCX","PSMobile") |
% { "http://www.codeplex.com/{0}" -f $_ }

"Oisin Grehan" wrote:
Oisin,
thanks for your help!