UPDATE 2: PowerKits requires PowerShell 2.0.  If you’re seeing errors regarding the “try-catch” keywords, its because those keywords were added in PowerShell 2.0 and I use them in PowerKits.  Sorry!

UPDATE: It turns out PowerShell 2.0 already contains a feature like this: “Modules.”  See here for more info.  Since it seems to be far superior to PowerKit (which I just hacked together for my own needs), I guess that just leaves this as an interesting exercise :).

I’ve been a huge fan of Windows PowerShell since it first came out as “Monad” (aka “MSH”).  Now that its entering version 2.0, which will be built-in to Windows 7 and Windows Server 2008, I’m getting even more into it.  I’ve written a Podcast Receiver (PowerCast) and an automated process for converting videos for use on my Xbox 360 (PowerCode).

[The following paragraph is a short intro to PowerShell, feel free to skip it if you’re familiar with PoSH]

What is PowerShell?  PowerShell is an object-oriented shell which, IMHO, kicks the pants off of BASH and Perl.  PowerShell is a dynamically-typed scripting language written on the .Net Framework, which gives you full access to every class, method, and property in the framework.  You could write a GUI, Server, heck even a 3D Game in PowerShell (it just might not perform as well as another language).  PowerShell is also an interactive “Read-Eval-Print” loop application which gives you a prompt into which you type commands which are then evaluated and their results printed to the screen (i.e. a standard “Shell” similar to cmd.exe or BASH).  Finally, PowerShell is an embeddable scripting environment which lets any .Net-based application embed the PowerShell scripting language.  However, most people (myself included) are referring to the Shell itself when they talk about PowerShell

Anyway, on to the main purpose of this post.  I started to get frustrated with trying to manage all my scripts and keep them organized.  I was also downloading a lot of useful scripts off of the web, but had to manually place them somewhere in my file-system (let alone managing all the dependencies).  Other scripting environments, such as Ruby, have packaging systems, such as RubyGems, to manage libraries of functionality and publish them for others to download.  So, I thought, why doesn’t PowerShell have something like this?

Thus, PowerKits were born.  The concept is simple.  A PowerKit is a directory on your file-system which contains a manifest file “Kit.xml”.  This file specifies some information such as the paths to various script files, aliases to create, .Net assemblies to load and (in a future version) PowerShell “snap-ins” to load.  After installing a kit (by placing it in one of many, configurable, pre-defined folders), it can simply be enabled using a single PowerShell Command.  For example, to enable the “MyCompany.MyKit” PowerKit:

Enable-Kit MyCompany.MyKit

Enabling a kit loads all the assemblies, script files, etc. into your PowerShell environment, making them available for use.  A Kit can then be disabled similarly using the ”Disable-Kit” command.  Disabling the kit removes all the script files, etc. from the environment (NOTE: .Net assemblies cannot be unloaded without restarting PowerShell, due to a limitation of the .Net Framework).

PowerKit also supports packaging kits into a ZIP-like format, specifically the Open Packaging Convention developed by Microsoft for Office 2007 (since the .Net framework has built-in support for that format). These “Kit Archives” can be downloaded and installed using a single command.  Eventually, I plan to add support for installing a kit directly from the web, so you could use a command like this:

Install-Kit http://www.mycompany.com/MyCompany.MyKit.kit

Or even this:

Install-Kit MyCompany.MyKit

And the framework would go out and download the kit and install it, giving PowerShell a true “gems-esque” packaging system.

To install PowerKit, download the Install-PowerKit.ps1 script from the CodePlex site, more installation details are in the release notes on that page.