Docker: Run containers as detached processes

I’ve recently run into an issue while updating the docker infrastructure on my local machine. Therefore I’ve lost all my previous containers and images and I had to reinstall them again.

Here are all the command lines to do that:

  • Elasticsearch:
    docker run --name elastic -d -p 9200:9200 -p 9300:9300 elasticsearch
  • Kibana:
    docker run --name kibana -d -p 5601:5601 --link elastic:elasticsearch kibana

    Note: The Elasticsearch container must be up and running in order to run this command.

  • EventStore:
    docker run --name eventstore -d -p 2113:2113 -p 1113:1113 eventstore/eventstore
  • Couchbase:
    docker run --name couchbase -d -p 8091-8094:8091-8094 -p 11210:11210 couchbase
  • RavenDB 4 (beta):
    docker run --name ravendb -d -p 8081:8080 -p 38888:38888 -e "AllowAnonymousUserToAccessTheServer=true" ravendb/ravendb

    On port 8080 there’s already a legacy version of RavenDB running on my local machine, so I have to map the port to 8081.
    Remember: The left side of the colon maps to the local machine while the right side maps to the container.

  • Jetbrains Teamcity:
    docker run --name teamcity -d -p 8111:8111 jetbrains/teamcity-server

Once the containers are installed, they are in a running state by default.
They can be stopped by running docker stop [container-name] and be started again by running
docker start [container-name]

Yeoman-Generator: froko-angular-seed

 I’m very happy to announce that my first Yeoman generator for Angular (v4) is now available on the official generator directory.
It’s called froko-angular-seed and is based on my own seed project with the same name.

Here are the links to the corresponding GitHub repositories:

– Seed-Project:
– Yeoman-Generator:

I plan to write a bunch of blog posts about this seed project, Angular itself and some interesting 3rd party libraries in the near future.

Stay tuned!

Misleading CORS exception turns out to be an IIS issue

Last week I got stuck on a deployment issue, which took me about a day to resolve. So I think this is worth sharing with you. For our next software release we developed an AngularJS application with an ASP.NET WebAPI backend and token based OAuth2 authentication. Local execution worked like a charm and the deployment to the first test server wasn’t an issue at all. But on the second test server we kept getting a CORS exception like this:

No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://localhost:7812‘ is therefore not allowed access.

Endless hours of web researches followed, but nothing seemed to help, neither various strategies on enabling CORS in the backend nor fiddling around with the web.config. After comparing the IIS settings on the second test server with the ones on the first working test server for three times (!) I finally found the difference which caused the error above:



.NET Authorization Rules on first test server



.NET Authorization Rules on second test server


Well, it does look very similar but it isn’t! By setting the authorization rule to “Allow All Users” the problem could finally be solved. Yet another example of how a misleading error message can cost you a valuable day of work!

How to Solve the TFS 2015 HTTPS Push Limit Size Problem

This is a guest post from Marco Röösli.

We had the problem, that our Git clients were not able to push big files onto the TFS Git server over HTTPS. It seems that some Git clients have a problem with the crypto algorithm tls_rsa_with_aes_256_cbc_sha.

Although it’s possible to setup Git clients to force using another crypto algorithm it’s not the favorite solution because all clients need to be updated this way.

The IIS Server where TFS is running has an order of crypto algorithm which should be used. To prevent Git configurations on each client, you can change this order.

This approach worked for us:

Change the order of crypto algorithms: tls_rsa_with_rc4_128_sha must be set before tls_rsa_with_aes_256_cbc_sha and more secure crypto algorithms than tls_rsa_with_aes_256_cbc_sha must be set before tls_rsa_with_rc4_128_sha.

The most Git clients do not support more secure crypto algorithms than tls_rsa_with_aes_256_cbc_sha. Therefore, the crypto algorithm tls_rsa_with_rc4_128_sha will be used for Git clients and this solves push limitations.

The most of all browsers do support more secure crypto algorithms than tls_rsa_with_aes_256_cbc_sha. For browsing on TFS, it will still use the most secure crypt algorithms available.

Caution! In order to make this changes work, a reboot of the TFS server is required!

You can change the order of the crypto algorithms using this tool: (


Or you can set it directly in the Windows registry:



Visual Studio 2015: Restore NuGet Packages With Build Script

With Visual Studio 2012 and 2013 you were able to enable the NuGet Package Restore within the context menu of the solution node:


With Visual Studio 2015 this menu item is missing:


When the NuGet Package Restore was enabled, the packages have been restored even when the solution was built outside Visual Studio with – let’s say MSBuild.exe – inside a build script.

Since this feature is not available anymore in the newest version of Visual Studio you have to do an extra step in your build script. My build scripts always look like this:

$baseDir = Resolve-Path ..
$scriptsDir = "$baseDir\scripts"
$sourceDir = "$baseDir\source"
$nugetCommand = "$sourceDir\.nuget\NuGet.exe"
$solutionFile = "$sourceDir\[YourSolution].sln"

$nugetCommand restore $solutionFile

msbuild $solutionFile /target:Rebuild /p:Configuration=Release

To make this work, you have to create a new folder named .nuget in the solution directory and copy a version of NuGet.exe into this directory like it would be if you have created the solution with Visual Studio 2013.