The default value is 150, which seems well and good for most commands. However, this is the second time I have run into it with different commands so I think it is worth noting. After upping the config to 512, all was right with the world again.

set-item wsman:localhost\Shell\MaxMemoryPerShellMB 512

I have to say i love the new WSMAN: provider. It makes something that was incredibly difficult to manipulate a snap.

Hope that helps,

Andy

Currently, there are no default UI options to set the color for the Script Pane, the Command Pane, or the Output Pane. However, these can all be changed using $psISE.

I wrote a few functions to help with this.

function Set-CommandBackPaneColor {
param
(
    [parameter(Mandatory=$true,ValueFromPipeline=$true)]
    $color
)
    $psise.Options.CommandPaneBackground = $color
}

function Set-OutputPaneColor {
param
(
    [parameter(Mandatory=$true,ValueFromPipeline=$true)]
    $color
)
    $psise.Options.OutputPaneBackground = $color
    $psise.Options.OutputPaneTextBackground = $color
}

function Set-ScriptPaneColor {
param
(
    [parameter(Mandatory=$true,ValueFromPipeline=$true)]
    $color
)
    $psise.Options.ScriptPaneBackground = $color
}

Automatically generated with a custom version of Write-CommandBlogPost

Set-OutputPaneColor sets two options, OutputPaneBackground and OutputPaneTextBackground. I have found that I like to have these the same, but you can easily separate them out if you like.

The last little tidbit is figuring out how to get a color picker rather than typing in the name of the color. We can accomplish this with a little Winforms action.

function Get-Color {
    $colorDialog = new-object System.Windows.Forms.ColorDialog
    $colorDialog.AllowFullOpen = $false
    [void]$colorDialog.ShowDialog()
    $colorDialog.Color.Name
}

Automatically generated with a custom version of Write-CommandBlogPost

This will return the name of the color that was picked

After clicking on Red, I get the following output

So now we can tie this all together with one final line to add a custom menu to ISE

[void]$psISE.CustomMenu.Submenus.Add("Output Pane Color", {Get-Color | Set-OutputPaneColor},$null)

I just passed in Null because I didn’t want a keyboard shortcut, but you can use one pretty easily.

So now I get the following:

I could set up Menus to set other color options for the script and command panes as well, but I figure that is enough screenshots to make the point.

The other custom commands are from Karl Prosser. I highly recommend you take a look at them as well. Very useful.

So there is one (not so subtle) flaw in the get-color function. It does not always place the color dialog on the top, so sometimes I have to Alt-Tab over to it. There is probably some nifty way with winforms to make it show up on top all the time, but I figured I would get this out there and then work on that little part.

Secondly, not all the colors work right now.

start /w ocsetup MicrosoftWindowsPowerShell

Note that ocsetup is case sensitive and you need to get the name of the feature and/or role exactly right.

Once you get the feature installed, you can launch powershell from the cmd prompt by using the full path to c:\windows\system32\windowspowershell\v1.0\powershell.exe.

Now that we have PowerShell V2 running, we can get-started with Remoting. To enable V2 remoting, there is a built-function called Enable-PSRemoting which typically is all you need. However, there is a known issue with Windows 7 Beta x64 systems where WOW components are not installed – a category which server core falls into.

If you try to enable remoting, you will get an error about a corrupted plugin in WSMAN.

To work around this, you need to remote a registry value. Run the following command

remove-item HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\Microsoft.PowerShell32

After that, you can run Enable-PSRemoting and you are good to go.

Turns out with V2 it is very simple to implement some sanity checking in the functions we write so people don’t go and blow their pinky tow off with a shotgun. So the trick is a simple IF statement in the PROCESS Block of your script or function.

There is a variable called $PSCmdlet that you can use to determine if the user entered the -confirm or -whatif switch. The first parameter in the ShouldProcess method is the target and the second parameter is the operation. Note that if the operation is not specified, it will default to the name of the function.

Here I have a parameter called $test and if I type -confirm it will ask me if I want to “Destroy Everything” on target “Whatever the value of $test is”

The ISE gives a nice Windows dialog box with the options when I type “Get-Something “That you can see” -confirm

I posted the code up on PoshCode here.

First, go and download the September 2008 CTP of F#. Once you have this installed, launch the 32 bit version of PowerShell. I’m using a 64 bit Vista machine and I had problems with the 64 bit version of Powershell with one line which I will get to in a bit. I think it has to do with the F# CodeDom Provider, not with PowerShell itself.

The F# CodeDom.dll was installed in C:\Program Files (x86)\FSharp-1.9.2.9\bin for me. Your mileage may vary. Anyway, cd into the bin directory of F# and you will find a file called FSharp.Compiler.CodeDom.dll. Once you are there, you can run the following lines to load up the F# Code Provider.

Add-Type -Path FSharp.Compiler.CodeDom.dll
$provider = New-Object Microsoft.FSharp.Compiler.CodeDom.FSharpCodeProvider
$fsharpCode = @"
let sample = [1;2;3;4;5;6;7]
"@
$fsharpType = Add-Type -TypeDefinition $fSharpCode -CodeDomProvider $provider -PassThru |
where { $_.IsPublic }
$fsharpType::sample

When you call Sample on $fsharpType, it will return the array with numbers 1 through 7.

For some reason when I ran this on a 64 bit I get the following error when I try to add the type with typeDefinition $fsharpCode on line 6

Add-Type : The system cannot find the file specified
At line:6 char:23
+ $fsharpType = Add-Type <<<<  -TypeDefinition $fSharpCode -CodeDomProvider $provider -PassThru | where { $_.IsPublic }
    + CategoryInfo          : NotSpecified: (:) [Add-Type], Win32Exception
    + FullyQualifiedErrorId : System.ComponentModel.Win32Exception,Microsoft.PowerShell.Commands.AddTypeCommand

If you are into this sort of thing, have fun!

Now I’m guessing if there is a way to use $psise.CustomMenu to add CommentBlock and UnCommentBlock commands.

One way to tackle this would be the following.

$text = $psise.CurrentOpenedFile.editor.SelectedText
$psise.CurrentOpenedFile.editor.InsertText("<# $text #>")      

Once you have this you can wrap it in a function and use Custom Menus to create a “Comment Block” Menu item.

Hope this helps.

Andy

The PowerShell team has taken this philosophy into the development of the ISE as well. In a couple previous posts here and here, I have talked about some very basic customizations using the $PSISE variable that comes with the Scripting Integrated Environment.

One thing I love about PS V2 is Advanced Functions. The only bummer is there is a lot of boilerplate text for each one. This sounds like a perfect opportunity for a code snippet. We can add some functions to our $PROFILE in the PowerShell ISE to make this happen.

First of all, we need to open our $profile script. It probably doesn’t exist so you can do the following. Note that the ISE is a PS host and it has its own profile, different than the one for PowerShell.exe that you use in Console.Exe.

new-item -type file -force $profile

Now we can open it in the ISE with the following line

$psise.CurrentOpenedRunspace.OpenedFiles.Add($profile) 

Now that we have the $profile open, we can create a function that will insert some text into the file that is currently being edited.

function Insert-Text
{
param(
    [parameter(Mandatory=$true, ValueFromPipeline=$true]
    [string]
    $text
    )
$currentFilePath = $psise.CurrentOpenedFile.FullPath
$currentFile = $psIse.CurrentOpenedRunspace.OpenedFiles |
               where {$_.FullPath -eq $currentFilePath}
$currentFile.editor.InsertText($text)
}

This function will insert text into the current script at the cursor’s location.

Now we need to write the actual snippet, which can also be a function

function New-FunctionTemplate
{
$f = @"
function Verb-Noun {
param (
    [parameter(Mandatory=$true, ValueFromPipeline=$true)
    [string]
    $p1
)
begin {}
process {}
end {}
}
"@
Insert-Text -text $f
}

The last line uses the Insert-Text function that we just created and inserts the snippet that is stored in the HereString $f.

Now we need to put it together and create a shortcut key and a new custom menu to insert this text.

$psIse.CustomMenu.Submenus.Add("_Function Template", {New-FunctionTemplate}, "Alt+F")

For this particular instance, I chose the name New FunctionTemplate and used Alt F for the keyboard shortcut.

You can use the CustomMenu class like so.

   1: $psIse.CustomMenu.Submenus.Add("_Dir", {dir}, "Ctrl+D")

In addition to the keyboard shortcut, you also get a menu as well.

Now when you hit Ctrl-D, it will run the dir command. All kinds of cool things are available within the editor with the new object model.

This actually makes a lot of sense IMHO. One of the beauties of this is that there is a smooth path from a basic function to an advanced function

   1: PS C:\> function foo {"foo $args"}

   2: PS C:\> foo bar

   3: foo bar

   4: PS C:\> function foo ($a) {"foo $a"}

   5: PS C:\> foo -a bar

   6: foo bar

   7: PS C:\> function foo {param($a) "foo $a"}

   8: PS C:\> foo -a bar

   9: foo bar

  10: PS C:\> function foo {param([Parameter(ValueFromPipeline=$true)]$a) "foo $a"}

  11: PS C:\> "bar" | foo

  12: foo bar

  13: PS C:\> foo bar

  14: foo bar

  15: PS C:\> foo -a bar

  16: foo bar

  17: PS C:\>

Just by setting some attributes on a parameter, you can get all kinds of great functionality for free.

Jeffrey’s function “Test-LeapYear” is a great example or template to start with. I really like how he used multi-line comments for all the Help documentation. Very slick.