Auth0: Invalid grant types: client_credentials

Today I wanted to change the settings of one of my Auth0 accounts. When hitting the save button, I got the error message “Invalid grant types: client_credentials”


The error was pretty confusing since I was not changing anything related to grant types.

After clicking around a bit, I notice the new tab for “Grant Types” in the “Advanced Settings” section. In this section, “Client Credentials” was checked but the option was disabled.


Simply de-selecting the option was not possible because it was disabled. Luckily, unchecking any other option, also updated “Client Credentials”.


Afterwards, I added the other option back and as soon as “Client Credentials” was unchecked, everything started working again.


TeamCity + XUnit: Not all tests executed

Running unit test on a TeamCity is usually not a big problem but a couple of days ago I noticed I very strange behaviour.

The number of tests executed on the build server was much smaller than the number of tests running on my local machine but TeamCity did not report any errors. After digging into the build log, I noticed this exception in the log files:
System.Runtime.Serialization.SerializationException: Unable to find assembly 'FakeItEasy, Version=, Culture=neutral, PublicKeyToken=eff28e2146d5fd2c'.

The only noticeable difference between the execution on TeamCity and my local machine was that locally I used the ReSharper test runner and on the build server xunit.console.exe was used to run the test.

When trying to run the tests with xunit.console.exe on my local machine I could reproduce the error.

For some unclear reason, XUnit was not able to load the FakeItEasy assembly that was located in the bin folder of the test assembly. The only workaround I found was to copy the FakeItEasy assembly to the folder of xunit.console.exe. After doing this, the number of tests on my local machine and on TeamCity matched again.

This is not really a satisfying solution, but I couldn’t find a better solution. Did someone find a proper solution for this problem?

File not found: azurermwebappdeployment.js

Recently our Visual Studio Team Services releases started to fail with the message

File not found: 'C:\Agent\_work\_tasks\AzureRmWebAppDeploy_497d490f-eea7-4f2b-ab94-48d9c1acdcb1\2.1.3\azurermwebappdeployment.js'

We changed nothing and the behaviour was pretty confusing. When checking the directory mentioned in the error message, the file was obviously not there but there was a zip archive “task”. This archive contained the script was well as some other folders.

Unzipping the archive in the folder did the trick and releases started working normally again. The correct folder should look like this:


Setup has detected Visual Studio Update 3 may not be completely installed.

Recently, I installed a new laptop with Visual Studio and the “normal” tool chain. While doing this, I encountered a strange error when installing the .NET Core tools.

NET Core Error

Setup has detected that Visual Studio 2015 Update 3 may not be completely installed. Please repair Visual Studio 2015 Update 3, then install this product again.

However, repairing Visual Studio did not solve the problem. Luckily, I found this StackOverflow post. The problem could easily be solved by starting the setup on the command line with this command:

DotNetCore.1.0.0-VS2015Tools.Preview2.exe SKIP_VSU_CHECK=1

Create custom Bamboo Agent Image Configuration

Bamboo is a great build server and the possibility to use EC2 instances as build agents makes it really cost efficient and flexible. But – most of the time, the stock images provided by Atlassian need to be customized to fit the purpose. But how to do this properly?

The easiest way is to create a new AMI based on the stock images and customize it.

  1. Launch a new instance using on of the existing AMIs (e.g. ami-ed6deb9e for the Ubuntu stock image) or use an instance launched by Bamboo
  2. Connect to it using SSH and customize it.
  3. Open the EC2 management console, select the instance and choose Actions -> Image -> Create Image
  4. Afterwards you need to enter a name and choose Create ImageScreen Shot 2016-05-15 at 20.44.07
  5. Copy the AMI id
  6. Switch back to Bamboo and navigate to Bamboo administration -> Image configurations
  7. Create a new configuration using the AMI id you copied beforeScreen Shot 2016-05-15 at 20.48.37
  8. You can now launch build agents with you custom setup

Powershell OpenFileDialog is not showing up

Recently I was writing scripts that should run on a Windows 7 machine. One task was to select a file and read it. So I used the usual snippet:

$OpenFileDialog = New-Object System.Windows.Forms.OpenFileDialog

I ran the script from PowerShell ISE during development and everything worked fine but when the users executed the script, the file dialog did not open up. Then I came across this page here and it said ShowHelp solves the problem. I changed the script to:

$OpenFileDialog = New-Object System.Windows.Forms.OpenFileDialog
$OpenFileDialog.ShowHelp = $true

I am not sure why, but this solved the problem and did not cause any other side effect. I am wondering what ShowHelp actual does because it seems to have no visible effect.

EB Command Line Interface: Error: Command returned non-zero status: status=256

When installing the EB Command Line Interface on a Mac I came across this error several times:
Running cmd: ln -s ~/.ebvenv/bin/eb /usr/local/bin/eb
ln: /usr/local/bin/eb: Permission denied
Error setting up link to /usr/local/bin. Add "alias eb=~/.ebvenv/bin/eb" to your profile.
Error: Command returned non-zero status: status=256

I am not sure what causes the error because all I did was executing:

curl -s | python

The error also states the solution: Simply open ~/.bash_profile and add the following line:

alias eb=~/.ebvenv/bin/eb

Bower install / NPM install behind a proxy

Often when you work in a company network your are using a proxy to connect to the internet and it is not uncommon that you receive the following error when trying to execute bower install or npm install

ECMDERR Failed to execute "git ls-remote --tags --heads git://", exit code of #128

The proxy is blocking the connection to Github because most proxy do not allow git://-urls. The solution for this is very simple. Just change the git urls to https and everything will work. This command changes all github urls to https:

git config --global url. git://

Not enough physical memory is available to power on this virtual machine with its configured settings.

Virtual Machines are more or less commodity for modern development environments. I have been very happy with VMWare Workstation for a long time. I have several SharePoint (and other) setups running and never had a problem.

Recently, I got the message

Not enough physical memory is available to power on this virtual machine with its configured settings.

whenever I tried to start a virtual machine. But my workstation had more than enough free memory available. Even restarting did not solve the problem. Google told me that a windows update could be the problem but I found only very old KB’s as potential causes.

By accident I stumbled upon a post that pointed to VMWare config.ini. Just add this line:

vmmon.disableHostParameters = "TRUE"

to the end of the file and VMWare starts working again. I am not exactly sure what the cause of the problem was, but at least I know how a workaround.

Logstash – File input not working on Windows

Logstash is a great tool to transform the information stored in unstructured log files into a structured format. When using it on a Windows machine there are several things you should pay attention to (and which are not 100% documented).

Let’s say you want to use a file input and specify it in this way:

input {
    path => ["C:\Logs\*.logs"]

When you run Logstash nothing happens and your files are not processed.

The reason for that is pretty simple: Logstash doesn’t like the \ and because of that it does not recognise the path properly. So simply change the config to look like this:

input {
    path => ["C:/Logs/*.logs"]

Always use in Logstash configs and you will easily get around this problem. The problem is also known to the Logstash community (see this bug) but there is no fix in place yet.


The mechanism for detecting which files have been written and which log entries are new is also not working correctly on Windows (see this bug here). The link also contains information on how to get around this problem.