While developing unit and functional tests for Windows Installer PowerShell Extensions, I needed a way to invoke cmdlets without requiring elevation on Vista. That is, of course, because running elevated has always been a bad idea unless it is required. In order to load a PowerShell snap-in, however, one must write to HKEY_LOCAL_MACHINE which requires elevated privileges. Other than that, there really isn’t another reason to run elevated.

Fortunately, PowerShell allows developers to define a RunspaceConfiguration object which, among other properties, allows developers to add specific types as cmdlets. Without being defined by a registered snap-in, cmdlets can then be invoked in a Runspace as shown below in a sample Visual Studio test class.

using System;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
using Microsoft.Windows.Installer.PowerShell.Commands;
using Microsoft.VisualStudio.TestTools.UnitTesting;
[TestClass]
public class GetFileHashCommandTest
{
    private RunspaceConfiguration config;
    [TestInitialize]
    public void Initialize()
    {
        config = RunspaceConfiguration.Create();
        config.Cmdlets.Append(new CmdletConfigurationEntry(
            "Get-MSIFileHash",
            typeof(GetFileHashCommand),
            "Microsoft.Windows.Installer.PowerShell.dll-Help.xml"));
    }
    [TestMethod]
    [DeploymentItem(@"data\example.txt")]
    public void PathTest()
    {
        using (Runspace rs = RunspaceFactory.CreateRunspace(config))
        {
            rs.Open();
            using (Pipeline p = rs.CreatePipeline(@"get-msifilehash -path example.txt"))
            {
                Collection<PSObject> objs = p.Invoke();
                Assert.AreEqual<int>(1, objs.Count);
            }
        }
    }
}

When it is time to install and register your PowerShell snap-in, I recommend you take a look at the WiX PowerShell extension to avoid using managed custom actions which can also cause problems.