Screenshot of a Windows Powershell from WikiPedia

Lately I have been doing some work with PowerShell. PowerShell is a well known in the Windows IT Pro space when it comes to the automation of tasks. In todays fast paced world the idea of automating mundane tasks is an attractive idea. PowerShell brings forward the basic toolset to automate, not just mundane tasks, but set up entire environments. Since I do most of my day work in C# I wanted to share some of my insights into developing with PowerShell. Which should just be enough to get into trouble Winking smile


The development environments

PowerShell comes right out of the box on Windows 7 or higher machines and even comes with it’s own editor the PowerShell Integrated Scripting Environment (PowerShell ISE). PowerShell ISE allows you to edit PowerShell files which includes code highlighting and IntelliSense and run them in Debug mode (F5) or running the selected code parts (F8). It is even possible to set breakpoints (F9) which should make C# developers feel right at home.


An interactive PowerShell displays the output of the running script. The shell also comes in handy while debugging your code. At a given breakpoint you can inspect the variable by typing it's name into the console. There only rant I have about the PowerShell ISE is that the console not be reset. The only way this can be achieved is by restarting the editor and having to open (all) the files again.

Visual Studio

As a C# developer the daily driver usually is Visual Studio. If you can’t bear the thought of using a different Editor. Well you are covered. The experience is much like with the PowerShell ISE. So if you have any Visual Studio Plugins such as VsVim you do not want to miss this may be your preferred route.


If you haven’t installed PowerShell during the initial installation of Visual Studio. You can add PowerShell by modifying your Visual Studio installation. Open Programs and Features, choose Visual Studio and then select Change. In the dialog select Modify and choose PowerShell Tools for Visual Studio. Finally select Next.You might want to get a cup of your favourite beverage while the installation is taking place.

Visual Studio will create it’s usual Solution and Project files. This will result in some extra clutter that your average PowerShell developer might not recognise. Keep this in mind when you check those files into your repo.

Beyond Windows

PowerShell is usually run on top of the .Net Framework. As of lately PowerShell also supports running on .Net Core. This means your PowerShell scripts are not limited to Windows. You can write them also for Apple and Linux machines. One of the PowerShell editors of choice for Linux and Mac, would be Visual Studio Code and the PowerShell Plugin for it.


You can see an extensive description on how to use PowerShell with Visual Studio Code on the msdn website.

Why choose PowerShell over C# or CScript

reactions why ryan reynolds but why

Since PowerShell runs on the .Net Framework, why should we use PowerShell in the first place? Wouldn't it be easier to just write the code with C# in the first place? One of the best arguments in my opinion comes from the reason why PowerShell came to be. It is designed from it's roots up to automate IT tasks. There are many hooks in the OS or other major Services. Active Directory, IIS, Exchange and many more provide interfaces that can be consumed with PowerShell. So if your task is to automate a Windows environment, PowerShell will be able to consume and interact with many existing APIs. Making the task easier and less time consuming.

A fun fact is that the UI for configuring IIS actually performs PowerShell commands in the background. The identical commands are used when invoking them through a PowerShell script.

Since we are writing infrastructure code there is a good chance that an Ops person will end up maintaining it. There is a good chance that this person has an interest in putting in the effort of learning PowerShell. Since it is their day job and PowerShell is sought out to enable them during their daily tasks.

And third, it is always fun to dive into a new programming language. And finally PowerShell has a way to interact with C#. So if the need ever arises to get stuff done the good old C# way there is nothing stopping you Smile

Hello PowerShell

Before we end this post, let’s see the Hello World Example:

echo "Hello PowerShell"

Jup that is it, one line and we are done.

In the next post we will dive into the basics of writing PowerShell code.


There is more in this blog post series:


Zurich Xamarin User Group Logo

I had a great time on Thursday the 15. September 2016 at the Xamarin User Group in Zurich. Though having a little struggle with the latest updates which seemed to have a “minor” impact on my UI Tests to run on Windows i.e. Visual Studio I had a great time presenting and some interesting questions to chew on during answering.

Image of my talk at our great location at the impact hub.

After the Meetup there was the typical Pizza, Sweets, Beer, Water discussions that always spawn some new insights on topics. I want to thank all those who came to the talk and I’m looking forward hopefully seeing you dear reader at one of the upcoming Xamarin Meetups in Zurich.

Image of a Pizza - which made me hungry while just looking at it... well done to past-mark...

Plus I am thrilled to announce that I’m now a Co-Organizer of the Meetup together with Thomas Charrière and Reto Senn. So if you have any topics you would like to present or see presented be sure to reach out to me via  Twitter or just write a comment down bellow. If you simply wish to support our effort by providing some beverages do neither hesitate to contact me or one of my co-organizers Winking smile

Talk Content

You can find my slides here and the code on GitHub.


I recently wrote a UI test for an app which displayed a CSS ID which included a colon. The UI tree from the REPL looked like this:

Googling did bring me closer to a possible solution by suggesting to escape the colon with a backslash, which ended in the following output:

So no luck, before going into any detail here is how to solve the issue:



The reason why the colon has to be escaped that many times is because the string will be passed through multiple runtimes. Each will be interpreting and escaping the string anew. The differing count is due to how Xamarin UI Tests have to handle the platforms.


Many thanks to Tobias Røikjer from the Xamarin UI Testing team for pointing out how to solve this problem.


Blog title image showing github octocat and Visual Studio Logo

During this post I assume you are already familiar with GitHub. Visual Studio Team Services (VSTS) is a cloud hosted service which focuses on DevOps centric teams. You can use the integrated Git repository if you are looking for a private repository. But in case the project is already hosted on GitHub or it is an open source project. VSTS can act as a build server which supports 3rd party hosted repository. The path for integrating GitHub is one of the best predefined paths a thereby is one of those services. But it is that comes with a great support for integration.

VSTS is not a tool which is focused on a single task. It is rather a tool trying to deliver a common platform to support Teams that are living a DevOps mentality. Per default VSTS provides teams with a default tool set for source code management, build and testing. Plugins allow to bind in different tools for a certain task at hand e.g. versioning control. These plugins or external service endpoints allow to integrate GitHub as VCS with ease. I'll assume you meet the following preconditions:

  • Have a VSTS account
    • You can create your free account here.
  • Have a VSTS Project
  • Have a GitHub account
  • (Have the code repository pushed to GitHub)

Open the projects dashboard and then open the settings menu. In the Control panel of your project open the tab Services:

Tabs in the VSTS project control panel with services selected.

Then add a new service endpoint and select GitHub:

Adding a new service endpoint which includes a GitHub option.

In the following dialog give the connection a name I.e. GitHub. Note that if you are already logged in to GitHub with an account, this account will be used to make the connection. If you want to use another account. Try using the private mode of your browser while performing these steps.

Dialog for configuring the external GitHub service, simply select Authorize to proceed.

After tapping on Authorize your VSTS will be connected to your GitHub account. When configuring the build configuration for a project. It now is possible to select GitHub as the repository type I.e. select a repository hosted on GitHub.

Screen shot showing the repository tab in a build config which allows selecting GitHub as repository type.


In this post we saw how we can add GitHub as an external service to a VSTS project. After adding GitHub as a service. It is possible to select a GitHub repository within a build configuration. So you can now build source code from GitHub via VSTS. The integration at the time of writing is still limited to only the build process. It currently is not possible to reference code from GitHub in the planning part. Or see the repository in the code part of the VSTS web dashboard.



In this post we will look at how we can write UI tests for a Xamarin.Android app. The app which we are testing is a basic app based on the MVVM pattern. You can find a detailed blog post on the in and outs of the app under test here.

Assuming you already have a Xamarin Test Cloud (XTC) project added to your solution. As described in this former post. Lets get started by preparing the app for UI testing.

Enabling your Android app for the XTC tests

You do not have to do anything to enable your app to be compatible with XTC. That being said when writing a test with Xamarin Test Cloud. The test should not recognize a control by the content it is displaying. Rather it identifies a control via an ID which is not visible to the end user but rather a invisible ID. Setting this ID is best done via the accessibility label attribute. You can set this in the AXML code of your view i.e. control:

This ID will not have to change if the locale changes. Even if the location of the UI element changes it will still be found by the test. Thus IDs should be generally used to identify controls as they allow for higher resilient test code.

Writing Test(s)

After tuning our the UI code we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting off with or smaller apps (as it would be the case in this post). I usually prefer to use the REPL which is easy to use and can be invoked at any point in the test code.

When the UI is prepared accordingly we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting of with or smaller apps (as it would be the case in this post), I usually prefer to use the REPL which is easy to use and can be inserted to be started at any point in your code.

The REPL is especially useful once you have a large testing framework. Having a framework i.e. helpers in place you can run those before firing up the REPL. So you can start exploring and interacting with the UI right were you need to.


Starting the REPL is as easy as adding the following line to your test method:

You can see the entire apps visual tree outlined.

Now we can define the steps we want to perform in our test:

Note how the test takes screenshots at every stage. This allows to easily identify the steps on the Xamarin test cloud and give them a label. While this might seem to be a bit of an overkill for such a small sample. When writing larger tests naming your steps i.e. screen shots will help you narrowing down where an error is happening.
One good thing about the tests is that they also run well on your local machine. So using e.g. the al Studio we can execute the tests over the NUnit Runner:

shows resharper testrunner in visual studio after executing a test

You can choose to run the tests on an emulator or device as you like. Just select the desired target as you would when starting the application. Or submit it to the test cloud i.e. integrate it in our build process.


This post described how to get started writing automated UI tests with Xamarin Test Cloud for a Xamarin.Android. Showing you how to adopt your UI for writing resilient test. Based on NUnit the tests are running on a stable and battle proven foundation.

Keep in mind that UI tests should not be the only testing you rely on for testing your app. But in combination with Unit and Integration tests they can provide great value to your project. Running them on Xamarin Test Cloud allows you to run them on a sea of devices. Along with different versions of Android i.e. vendor flavours.

You can find the entire sample on GitHub.