Posts

Showing posts from January, 2013

Check a Powershell Script for syntax errors

I recently had the unfortunate experience of sending off Powershell scripts to a client, only for them to come back because they did not run. A missing double quote was the culprit, but there must be a way to nip the problem in the bud. The solution came from  this great post: param($path, [switch]$verbose) if ($verbose) {     $VerbosePreference = ‘Continue’ } trap { Write-Warning $_; $false; continue } & ` {     $contents = get-content $path     $contents = [string]::Join([Environment]::NewLine, $contents)     [void]$ExecutionContext.InvokeCommand.NewScriptBlock($contents)     Write-Verbose "Parsed without errors"     $true } A simple script to check scripts (who watches the watchmen?).  It taks the path of the script to be checked and returns a simple boolean result of the validity of the syntax. True genius. I have definitely added this as a step in my deployment process.

Create Nintex Constants in Powershell

My current project has the requirement of a 'dll free' installation. That means that all the good code that was written in C# to create Nintex Constants  (I used http://jaclynsaito.wordpress.com/2011/09/13/creating-nintex-workflow-constants-programmatically/  as a reference) is not allowed on any servers. Bummer. So, how was the problem solved? The solution: Powershells impressive 'Add-Type'. The syntax I used is something like this: Add-Type -TypeDefinition $source -Language CSharpVersion3 -ReferencedAssemblies $references -passThru  -ErrorAction SilentlyContinue (the official blurb is here ) The code is quite straightforward, but the real kicker is the ReferenceAssemblies. By default, Add-Type only gives a limited number of references (System.dll and System.Management.Automation.dll.) So, if I want to add a reference to Nintex.Workflow.dll (which is helpful when trying to add Nintex constants), I will need to provide the full path the dll as part of the refe

Introduction

Starting Out I have had the priviledge (and pain) of working on a SharePoint 2010 development project for the last 12 months. During that time, I have experienced the good, the bad and the weird that is SP 2010 development. I thought a blog would be good forum to share some of findings and solutions some of the interesting issues I have encounterd on my (limited) journey. Hopefully, some if it may actually be helpful. Most likely, I will be writing it for myself and the two people I pay to visit the site. It should be interesting .....