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.

Surface Pro 3 Keyboard not working. What to do?

This week I encountered a problem with my Surface Pro 3. The Type Cover was not working anymore. After a bit of googling I found the solution which worked for me. Here’s a step-by-step guidance:


  • Shutdown your Surface
  • Press and hold the Volume Up and Power buttons for, at least, 15 seconds.
  • The screen may flash the Surface logo or other things but keep the buttons held for the 15 seconds.
  • When you release them, your Surface should be powered off. Wait at least 10 seconds and then turn it on normally.

Taken from
(See Step A – The Basics)


GitFlow, GitVersion, Octopack: Increment Beta Build Number for NuGet Packages

Last week we ran into a problem with our Octopus deployment: After a bug fix on the release branch we noticed that the new build had not automatically been deployed to our staging system. The reason for this was quickly found. We expected that the NuGet Package version was incremented by one such as Package.1.2.3-beta0002, but it was still Package.1.2.3-beta0001. Therefore, Octopus took no action since this particular version was already deployed.

After all it turned out that the 4-digit number suffix won’t increment automatically no matter how many commits you have done on the release branch. The same behavior is also true for hotfix branches.

However on the develop branch the 4-digit number suffix in incremented on each commit as I would expect it to be since a commit has a side effect and build artifacts aren’t obviously the same as before.

So why are there different behaviors on the branches mentioned above? The very short and personal answer is: I don’t know! But at least I can tell you how you can manipulate the number suffix: The trick is to use tags. Let me explain this with an example using GitFlow [1].


Here are some comments:

Step 0
Initial commit on the master branch and creation of the develop branch.
The unstable number suffix starts with 0000 since no commit was made on the development branch. So far so good…

Steps 3, 9, 17
Branching of release and hotfix branches. The number suffix starts with 0001. Here I would expect it to be 0000 since no commit was yet made to this branches (see step 0).

Steps 6, 8, 14, 19
Creation of a new tags. This leads to the desired suffixes.
Please note: Without the tag the suffix would still be like the previous one!

Step 7
Interestingly the suffix is incremented automatically but only once!

Steps 10, 11, 12, 16, 17
After merging the release branch into develop I would expect to reset the suffix to 0000 since no ‘real’ commit was yet made to the develop branch. Therefore, all suffixes should be interpreted as suffix value minus 1. But that’s my personal interpretation… The important thing is that the suffix in incremented on every commit which is indeed the case.

Example setup
In order to extract the version numbers, I created a very simple Git repo with a text file and the latest stable version of GitVersion.exe [2]. In the text file, I incremented an arbitrary number so that I had something to commit. The version I took, was the one tagged with “NuGetVersion”:


I didn’t test the whole workflow with Octopack [3] but I have noticed before that the beta build number suffix wasn’t incremented either.

In summary, I’m still a big fan of the GitFlow model and tools like GitVersion.exe and Octopack even though there are some weird cases with automatic versioning. If you ran into similar problems, I hope that this post is somehow useful to you. If you even know a good reason for the versioning mentioned above behavior, please write it in the comments below!

[1] Gitflow
Gitflow Workflow by Atlassian
Introducing Gitflow by Datasift
A successful Git branching model by Vincent Driessen
Gitflow Cheat Sheet by Daniel Kummer

[2] GitVersion.exe
Introduction page by ParticularLabs
GitHub repository

[3] Octopack
Documentation by Octopus Deploy
GitHub repository