PowerShell x64 vs x86: set execution policy when using Visual Studio post build events

Running PowerShell scripts in the Post build events within a Visual Studio project? Getting errors telling you “running scripts is disabled on this system”?

Visual Studio Output window showing PowerShell execution error

While working on Office 365 Developer Patterns and Practices (PnP) solution OfficeDevPnP.PowerShell Commands I had troubles with building my solution. Visual Studio uses PowerShell x86 in the background instead of my default PowerShell which uses the x64 version.

Check PowerShell version: x64 versus x86

By running the following you can check the current version. Download the PowerShell function from Check-PSVersion.ps1

function Check-PSVersion { if ([System.IntPtr]::Size -eq 4) { # When equal to 4, then x86 Write-Host "Running x86 PowerShell session" } else { # When equal to 8, then x64 Write-Host "Running x64 PowerShell session" } } Check-PSVersion

Where to find the PowerShell executable for both x64 and x86

The x64 version of PowerShell (Windows 8.1) can be found under:


The x86 version of PowerShell (Windows 8.1) can be found under:


Change execution policy to use PowerShell in Visual Studio

Now we know we have two versions of PowerShell we can change the execution policy for the x86 version of PowerShell. Start the "C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe" with “Run as administrator”. Now change the execution policy accordantly.

Set-ExecutionPolicy Unrestricted


Develop, Build, Package and Deploy Apps for Office 2013 with Visual Studio 2013–European Office 365 Connect

On April 1st and 2nd in Haarlem (The Netherlands) the first European Office 365 Connect took place. Speakers from over the world (like Dan Holme, Seb Matthews, Marc Reguera and many more) visited Haarlem and did sessions related to Office 365.

I’ve done a session about Apps for Office together with Visual Studio 2013. This was a kind of follow-up session for “The New SharePoint Online Apps – Napa in Action” from Patrick Lamber. You can find my slide deck below.

The demo was around building a Wikipedia Task Pane app which leverages the Wikipedia API for searching Wikipedia. Below a screenshot of the Task Pane App for Office inside the Word 2013 (desktop) client.

Wikipedia Task Pane app inside Word 2013 client

Once the app was done it’s deployed to Windows Azure via a Web Deploy package and the XML manifest is made available to end-users to consume from the Corporate Catalog (hosted in SharePoint Online). After configuring the Office client the Corporate Catalog is available from within Word, Excel, PowerPoint.

Apps for Office catalog in Word (desktop) client

Download the demo sources here: http://1drv.ms/1pTuGx9

Why can’t I use .Include() with CSOM

While working on the SharePoint Client Browser for SharePoint 2010 and 2013 I wanted to optimize performance by using the .Include() method. Visual Studio did not show the method and the build broke. This post takes about the use of .Include() and  .IncludeWithDefaultProperties() and the reason why Visual Studio did not show/support both methods.


Not all properties within the CSOM are loaded by default when using the ClientContext.LoadQuery. This design decision is taken by the Product Team due performance optimization. They did provide an option to extend the properties loaded by using the .Include() or .IncludeWithDefaultProperties() Linq extensions for the SharePoint Client Side Object Model (CSOM).

The example code below shows the use of the .Include() method and loads all lists together with the related fields within 1 request. This optimizes performance by minimizing the overload for a second or even more queries.

The issue with using the .Include() comes when the code is slightly changed! Check the altered code example below!

using System; using System.Collections.Generic; using Microsoft.SharePoint.Client; namespace SharePointCSOMConsole { class Program { static void Main() { ClientContext clientContext = new ClientContext("http://intranet.contoso.com"); IEnumerable<List> lists = clientContext.LoadQuery( clientContext.Web.Lists.Include( list => list.Title, list => list.Hidden, list => list.Fields.Include( field => field.Title, field => field.Hidden))); clientContext.ExecuteQuery(); foreach (List list in lists) { Console.WriteLine("{0}List: {1}", list.Hidden ? "Hidden " : "", list.Title); foreach (Field field in list.Fields) Console.WriteLine(" {0}Field: {1}", field.Hidden ? "Hidden " : "", field.Title); } } } }

Visual Studio not showing .Include()

While working on the SharePoint Client Browser for SharePoint 2010 and 2013 I wanted to optimize performance by using the .Include() method. But my code did not allow me to use the .Include() method. The screenshot below shows Visual Studio source code editor with the missing extension method.

Altered code example, no allowing to use .Include()


Because I used a different using statement on the top the .Include() method was not shown. After changing the “using SP = Microsoft.SharePoint.Client;” back to “using Microsoft.SharePoint.Client;” the issue was resolved.

Integrate Beyond Compare with Visual Studio Source Control

Like everyone else, I have my own preferences to configure my development environment. One of the tools I’m using is Beyond Compare. Besides the main features of the tool, I like the integration with Visual Studio and Visual Studio Team Foundation (TFS) the best and it’s really simple! But I always forget the command and arguments to use. This is why I’m writing this post.

Configure Beyond Compare as version history compare tool for Visual Studio 2010:

  1. Open Visual Studio
  2. Open Tools » Options…
  3. In the tree on the left go to Source Control » Visual Studio Team Foundation
  4. Click Configure User Tools…
  5. Click Add…
  6. Set the following fields
    1. Extention: *
    2. Operation: Compare
    3. Command: C:\Program Files (x86)\Beyond Compare 3\BComp.exe
    4. Arguments: %1 %2 /readonly /lefttitle=%6 /righttitle=%7

The arguments allow you to control the behavior of Beyond Compare. Labels to use:

  • %1: Original file
  • %2: Modified file
  • %5: Diff command-line options
  • %6: Original file label
  • %7: Modified file label