I’m seeing a few errant companies have their installers throw their modules into ${env:systemroot}\WindowsPowerShell\1.0\Modules but this is not the right place. The only things that should go there are core operating system modules from Microsoft. So, where should you install them?

How to: Install a module for all users

1. Create the folder ${env:programfiles}\YourProduct\PowerShell\Modules\
2. Place your module (or modules) under this folder
3. Add the folder from step 1 to the system scoped environment variable PSModulePath; consider embedding %ProgramFiles% to keep the environment string as short as possible
4. Profit.

How to: Install a module for the current user

1. Test for, and create if necessary the folder which is the result of this call (or equivalent in managed code): join-path ([environment]::GetFolderPath("MyDocuments")) WindowsPowerShell\Modules
2. Copy your module or (modules) to folder at above
3. Profit.

It’s as easy as that.

I don’t generally write a lot of big scripts, but when I do, I usually fire up the PowerShell 2.0 graphical IDE. However, every time I use it to develop a module I always get irritated by the lack of any session management. When I hack away on a module, I usually have a couple of files open. I rarely finish a module in one sitting either, so I’ll come back to it in a day or two. I don’t always leave ISE open though so when I fire it up again I have to navigate to the location (or locations) where my files are and re-open them. Another annoying situation is playing with assemblies either by loading some external ones, or by using Add-Type to create your own in-memory types/classes. Debugging these things can get annoying as once loaded or created, you have to quit ISE to “clean” memory of all your dabblings. Well, I lie when I say you have to quit ISE. Strictly speaking, you can create a new tab with CTRL+T, close the old one and load all of your scripts into the new tab. Tabs are isolated from one another and assemblies loaded in one are not available elsewhere. So, taking advantage of this trick, let me introduce:

ISE Session Tools Module v1.0

I have more features planned for v1.1 to give ISE a proper “project” based feel to it, but in the interest of shipping something, v1.0 has the following features:

• AutoSaving of current session (files open in current tab.)
  • This can be disabled and manually controlled if desired.
• Prompt to reload last session on ISE open
  • A hint is shown to you reminding you of some of the files you had open.
  • Press <enter> to accept the default of “Yes, reload my last session.”
• Restarting of the current tab
  • Essentially cleaning memory and keeping your files open in the editor.
  • You get prompted for this action. Press <enter> to accept default of “Yes, restart this tab.”
• All commands available under “Add-ons” menu for the mouse-fixated.

The commands exported by the module are:

• Restart-PowerShellTab  (CTRL+ALT+R)
• Export-PowerShellTab (CTRL+ALT+S)
• Import-PowerShellTab (CTRL+ALT+L)
• Enable-AutoSaveSession (CTRL+ALT+A)
• Disable-AutoSaveSession (CTRL+ALT+X)

As you can see, they have hotkeys. This is possible because these commands are also bound to the “Add-ons” menu. I was careful to choose keys that do not interfere with IsePack if you like to use that module too.

Installing IseSessionTools

Extract the files  into a folder named “IseSessionTools” under <my documents>\WindowsPowerShell\Modules\. In my ISE $profile, I have the following lines at the end of the file:

Import-Module ISESessionTools
Enable-AutoSaveSession

If you want to clear your session, disable autosaving and delete the session file at ~\psise.session.clixml.

Download ISE Session Tools Module v1.0

Have fun!

I’ve always been jealous of XTerm’s uber-geeky console mode screensaver, CMatrix. It was written shortly after the Matrix came out about ten years ago, and when I first saw it I thought it was really cool. I accidentally ran into it again recently and thought: “Hey, I could write that for PowerShell.” So I did.

PowerShell Screen Saver

The Matrix animation code uses the RawUI interface and is probably not all that interesting. It uses a simple “game loop” routine, repeatedly calling a “Step” function on multiple instances of a custom object, each representing an animating vertical column of letters. Each column is a dynamic module instantiated using the “-ascustomobject” parameter to allow encapsulation of state. I had originally intended to just prototype it using immediate writes to the console buffer, then moving onto a “frame buffer” implementation whereby the entire screen would be rendered into a BufferCell[,] array with a single SetBufferContents each cycle. It turns out though that the simpler implementation runs fast enough so there’s no need to get fancy pants. The idle detection was a little trickier. It uses PowerShell 2.0’s Eventing feature to start an instance of System.Timers.Timer running in the background. Instead of starting and stopping the timer during idle detection, which is actually quite a sluggish operation, the timer’s Elapsed handler increments a global variable every second. Each time the prompt function executes, it resets the counter back to 0. If this variable reaches the timeout value (default 3 minutes) it will invoke the screen saver from within the event handler. This allows the screen saver to activate without any user interaction. When running in an Action handler like this, you have to use CTRL+C to exit it; for some reason the $host KeyAvailable property doesn’t work correctly in this context. If you manually invoke the screen saver with Start-ScreenSaver, you can hit any key to exit. There is also some extra state being kept to temporarily disable the timer when the screen saver is active, or if the user has issued Disable-ScreenSaver. The implementation is a PowerShell 2.0 Module named “ScreenSaver.” To set it up on your console (sorry, it doesn’t work in graphical shells like ISE, PowerGUI or PoshConsole) just put in the following three lines in your $profile after you have installed the module.

import-module screensaver
set-screensavertimeout (new-timespan -minutes 5)
enable-screensaver

There are a couple of self explanatory functions exported from the module: Enable-ScreenSaver, Disable-ScreenSaver, Set-ScreenSaverTimeout <timespan | int>, Get-ScreenSaverTimeout and Start-ScreenSaver. Remove-Module ScreenSaver will do the right thing and clean up, disposing the timer. By the way, it is possible to have implemented this without the user of global variables but it would have added more complexity for little gain.

Or view the source on PoshCode. Normally I would paste the code inline, but there’s a bit more than my normal posts would have. Feel free to clone the PoshCode script and add your own screen saver patterns. Btw, you can tweak the number of columns and the animation speed by examining the Start-ScreenSaver function.

Have fun!

Write your own PowerShell provider using only script, no C# required. Module definition is provided by a Windows PowerShell 2.0 Module, which may be pure script, binary or a mix of both.

Debugging is as easy as any ordinary ps1 script file:

All functions in backing module reflect the same signature as those found on MSDN. This means that you go to MSDN documentation on providers to learn about how to write the corresponding script.

Current Release PSProvider 0.4

Samples and Templates

• See Documentation

Roadmap

0.1

• ContainerCmdletProvider support through "ModuleBoundProvider" provider
• Demo provider included navigating a Hashtable
• Can be debugged in the debugger of your choice: console, ISE, PowerGUI.

0.2

• NavigationCmdletProvider support
• Providers rename to ContainerScriptProvider and TreeScriptProvider
• Container Sample & Tree Template modules
• Supports: Clear-Item, Copy-Item, Get-Item, Invoke-Item, Move-Item, New-Item, Remove-Item, Rename-Item, Set-Item

0.3

• IContentCmdletProvider support
• New Commands: New-ContentReader, New-ContentWriter implement IContentReader, IContentWriter
• Adds support for: Add-Content, Clear-Content, Get-Content, Set-Content

0.4 (Current Release)

• IPropertyCmdletProvider support
• Adds support for: Clear-ItemProperty, Copy-ItemProperty, Get-ItemProperty, Move-ItemProperty, New-ItemProperty, Remove-ItemProperty, Rename-ItemProperty, Set-ItemProperty

0.5

• Dynamic Parameter support

0.6

• Security Interfaces
• Adds support for: Get-ACL, Set-ACL

http://psprovider.codeplex.com/

These days I'm incredibly busy both in my professional and private life, so I’ve not had a lot of time to construct the usual meaty posts I like to write. Instead I figured I could write a series of short – very short – posts centered around the little tricks that you would need to be an efficient developer when targeting PowerShell. Here's the first tip: how to create a Runspace and have one or more Module(s) preloaded. The RunspaceInvoke class is a handy wrapper that will do most of the plumbing for you if you just want to run scripts or commands. If you want to manually construct your own Pipeline instances then you must work with the Runspace class directly.

    InitialSessionState initial = InitialSessionState.CreateDefault();
    initialSession.ImportPSModule(new[] { modulePathOrModuleName1, ... });
    Runspace runspace = RunspaceFactory.CreateRunspace(initial);
    runspace.Open();
    RunspaceInvoke invoker = new RunspaceInvoke(runspace);
    Collection<PSObject> results = invoker.Invoke("...");

Have fun!