We tend to write a lot of shared PowerShell functions and variable definitions which we package into a library script that we dot source into multiple scripts.  In order to really test a change to our library scripts it requires running our lengthy automated test harness that takes almost 18 hours to complete.  Cleary that isn’t ideal in terms of a quick test before checking in the script.  Here’s a trick I use on dot sourced scripts like this which is essentially a quick sanity test before checking them in.  Say you have a script with an issue e.g.:

@"
function Greeting($name) {
    "Hi there $name
}
"@ > test.ps1

Now let’s dot source this script:

& { . .\test.ps1 }
Encountered end of line while processing a string token.
At C:\TFS\CDF\Trunk\Tests\Scripts\test.ps1:2 char:5
+     " <<<< Hi there

Cool.  PowerShell tells me write away about the error.  We dot source this into a nested scope so we don’t modify/pollute the global scope.  This is a real simple way to check to see if your "DOT SOURCE LIBRARY SCRIPT" has any parse errors in it. 

NOTE: Be careful about running this on scripts that aren’t dot sourced because the script will actually execute.  I know – duh.  It is just in the case of a dot source library script there is (typically) no directly executable code (except for perhaps setting variables), so dot sourcing these scripts is usually harmless i.e. side-effect free. 

Let’s correct the script:

@"
function Greeting($name) {
    "Hi there $name"
}
"@ > test.ps1

& { . .\test.ps1 }

And now we get no errors.  Anyway that is probably obvious to a lot of folks but perhaps someone will find it useful.  🙂