#Create a connection object and open it.
[String]$cns="Data Source=XXX;Initial Catalog=Northwind;
   Integrated Security=True"
[System.Data.SqlClient.SqlConnection]$connection=New-Object
   -TypeName System.Data.SqlClient.SqlConnection -ArgumentList $cns
$connection.Open()

#Create a command and execute it.
[String]$query="SELECT FirstName, LastName
   FROM dbo.Employees ORDER BY LastName, FirstName"
[System.Data.SqlClient.SqlCommand]$command=New-Object
   -TypeName System.Data.SqlClient.SqlCommand
$command.Connection=$connection
$command.CommandText=$query
$r=$command.ExecuteReader()

#Iterate the result.
while($r.Read()) {

    #Read out first name.
    [String]$firstname=""
    if( -not $r.IsDBNull(0)) {
        $firstname=$r.GetString(0)
    }

    #Read out last name.
    [String]$lastname=""
    if( -not $r.IsDBNull(1)) {
        $lastname=$r.GetString(1)
    }

    #Display.
    Write-Output ($firstname + " " + $lastname)
}

#Close the reader.
$r.Close()

$connection.Close()
$connection.Dispose()

Here I use column indexes when referring to columns. A change in the SQL query will produce errors in the code that reads out the result. The solution is to call the GetOrdinal function of the reader to get the indexes of the columns, like this:

#Create a connection object and open it.
[String]$cns="Data Source=XXX;Initial Catalog=Northwind;
   Integrated Security=True"
[System.Data.SqlClient.SqlConnection]$connection=New-Object
   -TypeName System.Data.SqlClient.SqlConnection -ArgumentList $cns
$connection.Open()

#Create a command and execute it.
[String]$query="SELECT FirstName, LastName
   FROM dbo.Employees ORDER BY LastName, FirstName"
[System.Data.SqlClient.SqlCommand]$command=New-Object
   -TypeName System.Data.SqlClient.SqlCommand
$command.Connection=$connection
$command.CommandText=$query
$r=$command.ExecuteReader()

#Get use named columns.
[int]$Index_FirstName=$r.GetOrdinal("FirstName")
[int]$Index_LastName=$r.GetOrdinal("LastName")

#Iterate the result.
while($r.Read()) {

    #Read out first name.
    [String]$firstname=""
    if( -not $r.IsDBNull($Index_FirstName)) {
        $firstname=$r.GetString($Index_FirstName)
    }

    #Read out last name.
    [String]$lastname=""
    if( -not $r.IsDBNull($Index_LastName)) {
        $lastname=$r.GetString($Index_LastName)
    }

    #Display.
    Write-Output ($firstname + " " + $lastname)
}

#Close the reader.
$r.Close()

$connection.Close()
$connection.Dispose()

Now, if you change the the query, the reader will still find the desired columns.

#Load the Windows Forms library.
[string]$WindowsFormsLibrary =
"System.Windows.Forms,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"
[System.Reflection.Assembly]::Load($WindowsFormsLibrary)

#Load the Drawing library.
[string]$DrawingLibrary =
"System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
[System.Reflection.Assembly]::Load($DrawingLibrary)

#Create a window, and set its properties.
[System.Windows.Forms.Form]$f = New-Object System.Windows.Forms.Form
$f.Width = 500
$f.Height = 300

#Display the form.
$f.Show()
#Force a complete draw before we add any graphics.
$f.Refresh()

#Acquire the graphics interface.
[System.Drawing.Graphics]$g = $f.CreateGraphics()

#Draw anything you like here using GDI+.
$g.DrawLine([System.Drawing.Pens]::Black, 50, 20, 450, 250)
$g.DrawLine([System.Drawing.Pens]::Black, 450, 20, 50, 250)

#Dispose the graphics interface.
$g.Dispose()

#Wait for 5 seconds before closing it all down.
Start-Sleep -s 5
$f.Close()
$f.Dispose()

If we take the trouble to create a custom type based on the Form class, we can create form has double buffering enabled by definition, and is of correct size by definition. The size can be set from outside the form as shown above, but the DoubleBuffered property that controls double buffering could not. So by just replacing the predefined Form class with a custom extension, we are slightly closer to our goal.

#Load the Windows Forms library.
[string]$WindowsFormsLibrary =
"System.Windows.Forms,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"
[System.Reflection.Assembly]::Load($WindowsFormsLibrary)

#Load the Drawing library.
[string]$DrawingLibrary =
"System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
[System.Reflection.Assembly]::Load($DrawingLibrary)

#Create a custom form with double buffering.
$Refs = @("System.Windows.Forms", "System.Drawing")
Add-Type -ReferencedAssemblies $Refs @'
public class MyGraphicsForm:System.Windows.Forms.Form
{
   private System.ComponentModel.IContainer components = null;

   protected override void Dispose(bool disposing)
   {
      if (disposing && (components != null))
      {
         components.Dispose();
      }
      base.Dispose(disposing);
   }

   private void InitializeComponent()
   {
      this.SuspendLayout();
      this.ClientSize = new System.Drawing.Size(500, 300);
      this.DoubleBuffered = true;
      this.Text = "My graphics form";
      this.ResumeLayout(false);

   }
}
'@

#Create our custom window.
[System.Windows.Forms.Form]$f = New-Object MyGraphicsForm

#Display the form.
$f.Show()
#Force a complete draw before we add any graphics.
$f.Refresh()

#Acquire the graphics interface.
[System.Drawing.Graphics]$g = $f.CreateGraphics()

#Draw anything you like here using GDI+.
$g.DrawLine([System.Drawing.Pens]::Black, 50, 20, 450, 250)
$g.DrawLine([System.Drawing.Pens]::Black, 450, 20, 50, 250)

#Dispose the graphics interface.
$g.Dispose()

#Wait for 5 seconds before closing it all down.
Start-Sleep -s 5
$f.Close()
$f.Dispose()

To be continued.

When you type DIR, a list of DirectoryInfo and/or FileInfo objects are created and sent to the script host. Each object, no matter type, are displayed as strings, meaning that the directory name or file name is displayed. How ever, you can use the pipeline to access actual objects. I have some directories and a few files in my C root, so if I pipe the output from the DIR command to an iteration that displays the object’s type name, like so:

DIR C:\ | ForEach-Object { Write-Host $_.GetType().Name }

From that I will get the word DirectoryInfo for each directory and the word FileInfo for each file in my C root. These are the .NET classes that represent directories and files. Since the PowerShell pipeline actually is handling objects, you can use these objects by accessing the properties or calling the functions of each object. A simple task such as displaying the number of files in each directory, is a walk in the park, when the actual object you need to do this, already is in the pipeline.

DIR C:\ | ForEach-Object {
If ($_.GetType().Name -like "DirectoryInfo")
   {
      Write-Host $_.Name "(" $_.GetDirectories().Length
         " dirs and " $_.GetFiles().Length " files.)"
   }
}

The output for this, is the name of the directory and the number of child directories and files that it holds. I can see that my Windows folder holds 66 directories and 45 files.

Functions are defined using the function keyword. This code defines a function that doesn’t require any arguments:

#Define a function.
function DoSomething()
{
   Write-Output "Hello!"
}

#Call a function.
DoSomething

When defining parameters, you can choose what parameters that need to be strongly typed by adding the desired type name in front of the parameter. Here I have 3 calls to the TwoParams function. The first parameter can be anything, but the second must be and int. Both call 1 and call 2 will run, becase $a can accept a string or an int. Call 3 will fail because $b cannot be a string.

function TwoParams($a, [int]$b)
{
	$b = $b + 1
	Write-Output "a=$a"
	Write-Output "b=$b"
}

#Two correct calls.
Write-Output "Call 1"
TwoParams "Hello!" 10

Write-Output "Call 2"
TwoParams 20 20

Write-Output "Call 3 will fail!"
TwoParams 30 "Hello!"

Default values can be provided, so that omitted arguments still will have a value. In this case, it is assumed that the values 1 and 2 is passed to the function. All parameters are passed by value.

function TestingDefaults($a=1, $b=2)
{
	Write-Output "$a $b"
}

TestingDefaults

Now, let’s look at the strange things. All arguments that are sent in, but not declared in the function head, will be captured by the $args array. In this case, $args in SomeFunction will contain 4 elements, because 4 arguments are sent:

function SomeFunction()
{
	$NumberOfArguments=$args.length
	Write-Output "You gave me $NumberOfArguments arguments."
}

SomeFunction "10" "Hej" 5 10

But here, still 4 arguments are sent, but the first argument is declared, so that only 3 arguments are catched by the $args array:

function SomeFunction($x)
{
	$NumberOfArguments=$args.length
	Write-Output "You gave me $NumberOfArguments arguments."
}

SomeFunction "10" "Hej" 5 10

[System.Reflection.Assembly]::Load("System.Management, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")

The class you want to create an instance from is called ManagementClass, and to its constructor you pass the management path that you want to use. USB devices are located in the Win32_USBHub path, so that is the argument that I pass to the constructor.

$Man = New-Object System.Management.ManagementClass("Win32_USBHub")

The GetInstances function returns a collection of objects, each object representing a device that actually is connected. Just for being crazy, I will make my target variable type safe.

[System.Management.ManagementObjectCollection]$Devs = $Man.GetInstances()

Now I can use ForEach-Obect cmdlet to iterate through the collection. For each device, I will write out the name of the device, the system ID and a blank line.

$Devs | ForEach-Object {
	Write-Output $_.GetPropertyValue("Name").ToString()
	Write-Output $_.GetPropertyValue("DeviceID").ToString()
	Write-Output ""
}

Finally, I have to free the resouces I have used.

$Devs.Dispose()
$Man.Dispose()

When you run this code, you should see a list of devices that is registered as connected to your machine, including the USB hubs. If you connect a device and run the script again, that device will show up in the list. With this code as base, you could easily write programs that detects changes to the list. That is, programs that detects when a new device is added or removed. The last item should be the device you inserted while your computer was running, and the first items are the devices that were available at system startup.

[System.Reflection.Assembly]::Load("System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089")

…so that calls like this is possible:

[System.Windows.Forms.MessageBox]::Show("Hello!")

(To see the available assemblies, check the assembly folder in your Windows folder.)

When you use the Add-Type cmdlet to create your own types, the string that describes the type might need references as well. The required assemblies are specified in an array, and passed to the cmdlet as the -ReferencedAssemblies argument. This code adds a custom type…

$references = @("System.Windows.Forms")
Add-Type -ReferencedAssemblies $references @'
public class Test
{
   public void hej()
   {
      System.Windows.Forms.MessageBox.Show("Hello!");
   }
}
'@

…gives you a code that when invoked, does the same thing:

$test = New-Object Test
$test.hej()

The problem will show up if you have made any changes to your type and run your program again. The type called Test will already be loaded, so the Add-Type cmdlet will fail.

(If you run your program again, without changing your custom type definition, Add-Type will just be ignored – your type is there and everything is fine.)

Since types cannot be unloaded, you will need to unload your entire appdomain, and the easiest way to do this, is to close your PowerShell window. So any changes to a custom type, will be reflected in a new instance of PowerShell, thus in a new appdomain.

This is not a problem at all. Like always when you attempt to call a C function in a DLL, you must know how it is exposed. This is not unique for PowerShell. The name of the link library, the name of the entry point, and the parameter types. This gives you a huge number of functionality ready to call, including third party libraries and the Windows API.

I am going to use PowerShell to move the mouse cursor to location 100, 100 (left, top). The SetCursorPos function takes two integer values (X and Y) and returns a boolean. According to the Windows API documentation, the function resides in a library called User32.dll.

One way to do this, is to write Visual Basic code, use PowerShell to compile it to an assembly, and then use reflection to call it. But there is another way.

Create one array of arguments, and an array of argument types. In my case, since I’m calling the SetCursorPos function, this is what I need:

$parameterTypes = [UInt32], [UInt32]
$parameters = 100, 100

Then, the rest of the code is something written by Jouko Kynsijärvi, that Lee Holmes used to make the Invoke-Win32 function. This is my complete code. Three lines! Check this out!

#The parameter types.
$parameterTypes = [Int], [Int]

#The arguments.
$parameters = 100, 100

#The call. Library, return type, function name, types and values.
Invoke-Win32 "User32.dll" ([Bool]) "SetCursorPos" $parameterTypes $parameters

The rest of the listing is the definition of the Invoke-Win32 function that I extracted from this Lee Holmes’ post.

As you run this script, note how the mouse cursor jumps up to the upper left corner, 100 pixels from the left edge, 100 pixels from the top.

(I have a huge smile across my face when I’m writing this.)

Before you run it, make sure that the folder you write your exe to really exists. In my case, C:\temp.

First, let’s load an assembly. Remember, no line breaks here.

#Load the Visual Basic assembly go get the code
#that creates a compiler.
[System.Reflection.Assembly]::Load("Microsoft.VisualBasic, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")

Then we create the objects we need. The second line will cause some problems. The object returned by the CreateCompiler function has a method that isn’t exposed, so we can’t call it directly. Also note that we are specifying an output path here.

$VB = New-Object Microsoft.VisualBasic.VBCodeProvider
$Compiler = $VB.CreateCompiler()
$Params = New-Object System.CodeDom.Compiler.CompilerParameters
$Params.GenerateExecutable = $true
$Params.OutputAssembly = "C:\temp\myprogram.exe"

This is the code I want in my exe:

[String]$S = "Imports System`n"
$S = $S + "Module MyModule`n"
$S = $S + "Sub Main(ByVal Args() As String)`n"
$S = $S + "Console.WriteLine(`"Hello! Press Enter!`")`n"
$S = $S + "Console.ReadLine()`n"
$S = $S + "End Sub`n"
$S = $S + "End Module`n"

Now, I must use reflection to call the unexposed method. In C# or VB, this is not a problem because we can use interfaces. PowerShell can’t. Since the method expects two arguments, I will create an array with the two elements. Then, the Invoke method takes the object where the function resides and the arguments. Typing is important so that the correct function overload will be found.

#Extract the method "CompileAssemblyFromSource". (No line break here!)
$CompileMethod=
[System.CodeDom.Compiler.ICodeCompiler].GetMethod("CompileAssemblyFromSource")

#We must pass in the parameters and the source
#when calling.
$Args = New-Object System.Object[] 2
$Args[0] = [System.CodeDom.Compiler.CompilerParameters]$Params
$Args[1] = $S
$Res = $CompileMethod.Invoke($Compiler, $Args);

$VB.Dispose()

Now, you have your own executable file that greets you when you start it!

C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0

Also, scripting needs to be activated in PowerShell.

A RunSpace is a context where PowerShell scripts run. Any variables that are set in one runspace, can be read from that same runspace, but not any other runspace. Before the opening Using, I will create a variable (Result) that will hold the response from PowerShell.

Dim Result As _
   System.Collections.ObjectModel.Collection(Of System.Management.Automation.PSObject)

 Using R As System.Management.Automation.Runspaces.Runspace = _
   System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace()

Next, you open the runspace and create a pipeline.

R.Open()
Dim P As System.Management.Automation.Runspaces.Pipeline = R.CreatePipeline()

The pipeline has a Commands collection where you add your commands or complete scripts. These two lines will create two output objects.

P.Commands.Add("C:\test.ps1")

When you’re done, you can execute the script using the Invoke function of the pipeline object, and close your runspace. The response is saved in the Result variable I created earlier.

Result = P.Invoke()
R.Close()
End Using

For Each Res As System.Management.Automation.PSObject In Result
   MessageBox.Show(Res.ToString())
Next

The content of my script file, test.ps1, is:

Write-Output "Hello!"
$x = 10 + 3
Write-Output $x

The output of course will be one message box saying Hello! and another saying 13.

#Load some assemblys. (No line break!)
[System.Reflection.Assembly]::Load("WindowsBase,
   Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35")

#Create a zip file named "MyZipFile.zip". (No line break!)
$ZipPackage=[System.IO.Packaging.ZipPackage]::Open("C:\MyZipFile.zip",
   [System.IO.FileMode]"OpenOrCreate", [System.IO.FileAccess]"ReadWrite")

#The files I want to add to my archive:
$files = @("/Penguins.jpg", "/Lighthouse.jpg")

#For each file you want to add, we must extract the bytes
#and add them to a part of the zip file.
ForEach ($file In $files)
{
   $partName=New-Object System.Uri($file, [System.UriKind]"Relative")
   #Create each part. (No line break!)
   $part=$ZipPackage.CreatePart($partName, "application/zip",
      [System.IO.Packaging.CompressionOption]"Maximum")
   $bytes=[System.IO.File]::ReadAllBytes($file)
   $stream=$part.GetStream()
   $stream.Write($bytes, 0, $bytes.Length)
   $stream.Close()
}

#Close the package when we're done.
$ZipPackage.Close()

Now, my image files are archived to one ZIP file.