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: (https://www.nartac.com/Products/IISCrypto)


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 http://www.lovemysurface.net/keyboard-problems-with-surface/
(See Step A – The Basics)