Using Psake to build Visual Studio solutions

Psake is a build automation tool that can be used as an alternative to the ubiqutous MsBuild XML files for .NET developers. Psake is a module for Powershell and this means your build scripts will have easy access to other resources such as remote Web Servers and file systems or other required resources in the build process. In addition, building software is primarily a procedural process and using a script with the aid of Psake makes more sense than using MSBuild XML files. It is also quicker to avoid creating MSBuild tasks and so on. Let't take a look at a sample Psake build script:

#tasks.ps1            
            
properties {            
 $config = 'debug'; #debug or release             
}            
            
task -name PackageZip -depends Build -description "proceduces a zip archive of the build output" -action {            
    import-module pscx             
    write -host "Packaging files"            
    write-host $config             
    Push-Location 'C:\Users\Tore Aurstad\Documents\visual studio 2012\Projects\TestLDAP\TestLDAP\bin'            
    dir $config\ | write-zip -output $pwd\$config\TestLDAP.zip            
    Pop-Location            
}            
            
task -name ValidateConfig -action {            
 assert ( 'debug', 'release' -contains $config) `
 "Invalid config: $config; valid values are debug and release";             
}            
            
task -name Build -depends ValidateConfig -description "builds outdated source files" -action {            
    write-host 'The build task is now running';            
    exec {            
        msbuild 'C:\Users\Tore Aurstad\Documents\visual studio 2012\Projects\TestLDAP\TestLDAP.sln' /p:Configuration=$config            
    }            
}            
            
task -name Clean -description "deletes all build artifacts" -action {            
    write-host 'The clean task is now running';             
     exec {            
        msbuild 'C:\Users\Tore Aurstad\Documents\visual studio 2012\Projects\TestLDAP\TestLDAP.sln' /t:Clean /p:Configuration=$config             
    }            
}            
            
task -name Rebuild -depends Clean,Build -action {            
    write-host 'The rebuild task is now running';             
}            
            
task default -depends Build;

The following command then will invoke one of the build targets in the Psake build scripts:

PS C:\users\Tore Aurstad\Documents\WindowsPowerShell\scripts> invoke-psake -buildfile .\script1.ps1 -task PackageZip Before running the script1.ps script file, which I have put in the Scripts folder of the parent folder of the $env:psmodulepath. In addition, psake had to be installed. To install psake, download the .zip file of this Powershell module from the following url:

Psake Github

Save the .zip file to your hard disk, unblock the zip file using file properties and click Anvanced button. Unzip the file contents and move the files into the $env:psmodulespath folder, in a subfolder called psake.

When psake is ready on your system, check that you have the correct execution policy. Run if necessary: Set-ExecutionPolicy RemoteSigned in Powershell.

The psake script contains of multiple task declarations. The task default is obligatory. The other tasks has action blocks, and some of these calls msbuild inside an exec block.

The module pscx is also used to zip the output of running msbuild. The module is available here:
Pscx module. This module is the Powershell Community Extensions powershell module. The module is a central extension module of Powershell. By piping the output of the dir command against the output files and using the cmdlet write-zip and the argument -output following by the file name of the zip file to create, the output is zipped together.

Also make note that tasks can depend upon oter tasks with their -depends flag. To toggle between the debug or release configuration, it is possible to set this by using the -properties flag on the invoke-psake command. To build in release, simply specify this as in the following example:

PS C:\users\Tore Aurstad\Documents\WindowsPowerShell\scripts> invoke-psake -buildfile .\script1.ps1 -task Rebuild -properties @{ 'config' = 'release' } By setting -properties flag and passing in a hashtable where the key 'config' is set to the value 'release', it is possible to build in release mode instead of debug mode. There is also a ValidateConfig task that will check that the provided value is either 'debug' or 'release' or some other value. The assert expression will check that the specified configuration is one of the two valid values. There is a correspondence between the property in the -properties flag and the property declared in the psake script.

Psake can be integrated into TeamCity and you can transform the functionality of the MSBuild Xml file (usually a .proj file) into a psake script. Once this is done, it is much more flexible to make changes since the build script now is inside a Powershell script. Forget creating MSBuild tasks which are compiled, this will instead be other Powershell scripts.

Here is a tutorial on how to integrate psake in Team City:

Psake and Team City

Searching for text in files with Powershell

This article will present a way of searching for text in files on your hard disk using Powershell. There are of course many ways of achieving this, such as findstr command. I call the function I present here as grep, but this is in no way anything similar to the sophisticated grep tool many users from Unix-based operative systems are familiar with. The output this command gives gives a nice summary of line number and file

function grep($searchPattern, $fileMatch = '*.*', [bool] $ignoreCase = $true){            
             
 if ($ignoreCase){            
  Get-ChildItem -Recurse -Filter $fileMatch | Select-String -Pattern $searchPattern |            
  Format-Table -GroupBy Path -AutoSize            
 }            
 else {            
  Get-ChildItem -Recurse -Filter $fileMatch |             
  Select-String -Pattern $searchPattern -CaseSensitive |            
  Format-Table -GroupBy Path -AutoSize            
 }            
}            
            
grep AsFullName *.cs $true            

The cmdlet above is called grep, but this does not apply to the verb-noun standard of Powershell. A better name could be Search-Files or something similar. The function uses the Get-ChildItem cmdlet with the recurse option to search all files (and folders) recursively from the current working directory and all its subfolders. This is then piped to Select-String and the flag -CaseSensitive is set if $ignorecase is set to $false. As you can see, the default value of the second and third parameter to the function /cmdlet is '*.*' for $fileMatch and $true for $ignoreCase. A function call is done in the code shown above as an example. Make note that only the first parameter is required, the search string. If a case sensitive search is desired, one must specify all three parameters. If it is desired to search through all files, use '*.*'. In my example, I am looking through some source code, and I am only interested in looking at the files with the extension '.cs' (C# source code files).

It is possible to compact the function or cmdlet above by making use of emulating the ternary operator, but the script above is easy should be easy to debug. If $ignoreCase is set to $false, the -CaseSensitive flag is used in the Search-String cmdlet in the script above.

The output of the command is shown below, when the working directory is set to the source code folder where I have cloned the source code of ShellStudio:

PS C:\toaurs-he\StudioShell\studioshell[ default ]> grep AsFullName *.cs


   Path: C:\toaurs-he\StudioShell\studioshell\src\CodeOwls.StudioShell\CodeOwls.StudioShell.Paths\Items\CodeModel\ShellCodeTypeReference.cs

IgnoreCase LineNumber Line                                            Filename                  Path                                                                              
---------- ---------- ----                                            --------                  ----                                                                              
      True         54         public string AsFullName                ShellCodeTypeReference.cs C:\toaurs-he\StudioShell\studioshell\src\CodeOwls.StudioShell\CodeOwls.StudioSh...
      True         56             get { return _typeRef.AsFullName; } ShellCodeTypeReference.cs C:\toaurs-he\StudioShell\studioshell\src\CodeOwls.StudioShell\CodeOwls.StudioSh...

Using Studioshell to prefix booleans with Is

An often used convention used in coding is to prefix boolean properties that are public with the prefix Is. In this article, an automatic refactoring technique will be explained using Powershell. Alternatives could be using Resharper or Roslyn. Since Powershell will tackle this on a file level, it will execute very fast. Using Powershell alone will not be sufficient, since Powershell does not have the needed code analysis capabilities. To tackle this, we will useStudioshell and execute the script presented in this article.
To download Studioshell, visit the following url:
Studioshell codeplex page

As an alternative, download and install StudioShell via NuGet. Open up a new solution in Visual Studio, then choose the menu option Tools, Library Package Manager and Package manager console. Choose your main project or what's best suited and run the command:
Install-Package StudioShell.Beta

When StudioShell is installed, check that the Execution Policy is remote signed. Start Visual Studio as an administrator and run the following cmdlet: Set-ExecutionPolicy RemoteSigned . StudioShell has its own profile file. Let's first create the profile file, if necessary. Run the following cmdlet: New-Item -ItemType File $profile Add the following function to the $profile file, by running the following cmdlet to open up the $profile file in Notepad: Invoke-Item $profile The automatic refactoring function in Powershell with the help of StudioShell then looks like this:

function PrefixWithIs-Booleans(){            
 Set-Location dte:\solution\codemodel            
        dir -recurse | where { $_ -match 'property' -and $_.name -notMatch '^Is' -and $_.access -match 'public' -and             
        $_.type.asfullname -match 'bool' } | foreach { $newname = "Is" + $_.name; $_.renamesymbol($newname); }            
            
}

Of course, this function could be put in a .ps1 or .psm1 file instead of residing in your StudioShell profile file. By putting the function or cmdlet into the $profile file, it will always be available in StudioShell. As you can also see, the cmdlet is named with verb-noun, as is the convention in Powershell. To run this cmdlet, just type: PrefixWithIs-Booleans This cmdlet will automatically rename all public properties that return a boolean and that has not have the prefix Is, and rename this public property to have the prefix Is. This will result that all public properties start with Is. The cmdlet PrefixWithIs-Booleans starts with running the dir -recurse command to recursively look at all files (and folders) in subdirectories. But first the location is changed to dte:\solution\codemodel. Studioshell has a folder structure which is used for the analysis of code of the currently loaded solution. By then looking at all files (and folders) in the folder dte:\solution\codemodel, effectively one is looking at the entire Visual Studio solution. The property of the items one is looking at is CodeOwls.StudioShell.Paths.Items.CodeModel.ShellCodeProperty2. The command dir -recurse is piped to the cmdlet where and the long where condition effectively looks for boolean properties that are public and does not have a name starting with Is. The result set is then furter piped to foreach which will iterate on the current object in Powershell, $_ and then call the renamesymbol method of the current object. The new name is then set to Is + name member of current object. This shows how Studioshell can refactor a Visual Studio solution using the dte: folder structure of Studioshell and then to code manipulation on the Visual Studio. It is important to be careful when using Studioshell, I would suggest using a versioning system such as Mercurial. Studioshell can also automate a multitude of features in Visual Studio besides code manipulation and code analysis. For example, it is possible to save window layout and load up a window layout with a single command from the shell command line of Studioshell inside Visual Studio. It is also possible to toggle on and off all breakpoints and so on. If you find yourself doing repetitive tasks in Visual Studio or changing the code in a repetitive manner, consider using StudioShell for automating these tasks.