Web Deploy – Retrying the sync because a socket error (10054) occurred

I was recently setting up Web Deploy for a customer (there are quite a few steps to this) and when I tried to deploy the project to the remote server received the following error:

Warning               1              Retrying the sync because a socket error (10054) occurred.

Retrying operation ‘Serialization’ on object sitemanifest (sourcePath). Attempt 1 of 10.                 0              0                TestWebDeploy

This was the first time I have set this up on a remote machine so thought it must be some kind of firewall interference as it all seemed to work locally. Web Deploy requires port 8172 open by default but I could Telnet to this without issue so the problem was something else.

Take a look at the following screen for configuring web deploy – one of the items you have to specify is the service url of the web deploy end point:

Web Deploy Screen

Microsoft even give you some examples of service end point such as: https://RemoteServer:8172/MsDeploy.axd so that’s the format I used.

Well turns out you dont want that http or https prefix and if you add it you will get the error above.

The correct format is actually: (obviously replace with your actual IP address)

You might now need to check the allow untrusted certificate option as well.

Thank you Microsoft for wasting 2 hrs of my time on this.

If this doesnt fix your issue then maybe you have a certificate binding problem check out this stack overflow post.

Web Directions – What do you know – Navigation API talk

Enjoyed the Web Directions – What do you know event where I presented on the Navigation API. I love the idea of 5 min talks and it was all run very smoothly. Think we will try this at DDD this year. Think I need to practice slowing down for this format 🙂

My slides etc are at:

Node.js er what’s it supposed to be used for?

<Disclaimer I am new to Node.js so this represents my current thoughts and additionally much of my development is on a Microsoft platform so I come from this perspective>

There is a lot of fuss in the web development community at the moment about Node.js and how it’s going to be the next big thing.

Node.js provides an environment to run JavaScript in and has been used successfully on a number of high traffic sites such as LinkedIn so I decided to investigate further. Now I really like JavaScript (although it has both the irritation and bonus that I discover something new about it every week) so I was keen to look into this technology and what I could potentially use it for.

The main arguments I have heard for using Node are:

  • It’s great for service type stuff as it’s more scalable because of its eventing model, no locks etc
  • A JavaScript runtime environment outside the web browser

Superior Scalability

One of the biggest claims you will hear from Node advocates is its superior scalability due to its use of call-backs (async) and no locking. The jury seems to be out on whether Node applications do actually scale better than other alternatives and there are countless blog posts arguing both ways. I don’t know enough about the low level detail to argue either way but let’s assume it’s pretty quick for certain scenarios (basically anything that’s IO bound is a potential candidate).

It’s important to also note that you can develop a similar scalable async model with .net although it certainly wasn’t as easy or intuitive as Node.js (especially without C#5’s Async features).

One thing I will say however in that my consultancy experience it is rarely the technology that is at fault when it comes to performance and let’s face it most of us don’t need our applications to be as scalable as something like LinkedIn or Facebook. More often than not performance issues are due to many calls being made to a database (usually multiple times) and the returning unnecessary data so I am not convinced as to this being a good enough reason to try out Node.

A way to run JavaScript outside the web browser

Node.js is pretty cool for playing around with JavaScript providing an environment for running your JavaScript applications and even a RPL interface. I came across an example of this last week when playing with the excellent CSSLint that used Node.js to tell me all the stuff I had screwed up when writing my CSS.

I was however left with the question of why I would actually want to write an application in JavaScript as there are so many existing (and easier?) ways of writing applications. If I want to knock off a quick prog to automate a tedious task or do something similar to CSSLint I am probably going to do it in C# with a mature set of well documented & maintained APIs and Visual Studio’s nice debugging environment. Of course JavaScript’s functional qualities make it very elegant for certain tasks and I can see there might be developers who only know JavaScript who now have another platform to develop on.

The issue however is that the very experienced JavaScript developers tend to have gained this experience from front end work so may not be the sort of people you want developing your services. But I guess its pretty cool that it opens up another option for JavaScript developers.

The second issue that bothered me was due to Node’s immaturity – would it have many libraries for tasks such as querying a database? Well I need not have worried as Node.js has a large community and a number of extensions (node packages) have been developed for performing common tasks so this shouldn’t be that much of an issue. I’m not sure I would trust a community developed interface to a product such as SQL Server to be as mature & up to date as Microsoft’s versions through.

Below are the main advantages I can see Node.js offers


  • Potentially more scalable for certain tasks
  • Developing certain types of services could be more intuitive
  • Node.js servuces are light weight and easy to modify
  • Anything has to be better than WCF (sorry Himanshu but WCF was written by the devil)
  • JavaScript is becoming a universal language & you can potentially run your code on multiple platforms
  • IISNode makes Node.js very easy to setup on Microsoft platform and benefit from IIS features such as logging, connections etc
  • Large number of packages/extensions available
  • Node.js apps can be hosted very cheaply compared to an MS based app e.g. Heroku
  • For the MS devs Node.js can be hosted on Azure (although its apparently a bit of a pain)
  • Could help progress JavaScripts development and standards e.g. common.js


  • How many apps actually need Nodes much touted scalability?
  • When used for Service development the devs that are experienced in writing service type code probably aren’t also those experienced in JavaScript (not always of course!)
  • How can a wrapper for something like SQL server be more efficient and feature rich than Microsofts implementations so any perf gains may be negated by usage of poor performing extensions
  • Packages may not be maintained aren’t as mature as traditional vendor options
  • Poor debugging experience (I understand there is a debugger browser extension available)
  • Immature technology – potential bugs and lack of devs skilled in this area
  • Can same “perf/scalability gains” be experienced with existing async functionality?

I’d love to have a really good solid reason to use Node.js but having spoken to a number of colleagues no one is yet to give me one.

Sure its cool but I am left with the question what are you actually going to use it for? Er..

I remain open minded and I’d love for someone to give me a good answer to this question 🙂

Setting up Node on Windows

There is a lot of fuss at the moment in the web development community about a framework called Node.js that allows you to run JavaScript server side. A number of claims about fantastic scalability and lack of locking have been made regarding Node – whether these are actually true and if the advantages outweigh the disadvantages is another question..

Let’s assume however you are a Windows user who wants to see what all the fuss is about and get up and running with Node.js..

Previously getting Node.js running on Windows was a little painful and involved some manual compilation, patching of libaries and an application called Cygwin that emulated a *nix environment.

But no more! getting Node.js running on Windows is now very easy and it can be hosted within IIS by installing IISNode. This is actually pretty important as allows you to take advantage of a number of IIS features thus answering the question of how Node should be managed/hosted on a Windows machine. It’s worth noting as well that Node.js is even supported on Windows Azure.

Below are instructions on how to install Node.js on Windows:

First you are going to need a Windows OS that is at least as new as Vista with the IIS URL Rewriter module installed (add/remove programs).

If this is all good then go download & install Node.js from http://nodejs.org/. At the time of writing the most recent version is held at: http://nodejs.org/dist/v0.6.10/node-v0.6.10.ms.

Next you want to get hold of IIS Node by going to https://github.com/tjanczuk/iisnode.

IIS node has its own installer at (src/setup/iisnode-msi/) run the installer. Once you have run the IIS node installer if you look under the Modules section in IIS you will see a new module has been created:

New Node module in IIS

The next step is to create a directory for your node application (note you can also incorporate a node endpoint into an existing application by adding an entry to web.config but let’s keep it simple).

Create a site or application to map through to this directory in IIS (to create an application right click on default website and select Add Application). I am calling my virtual directory AlexNode.

Now create 2 files within your directory:

  • test.js
  • web.config

Open test.js up in a text editor and enter the following hello world node code (this is from the IISNode example):

var http = require(‘http’);

http.createServer(function (req, res) {
res.writeHead(200, {‘Content-Type’: ‘text/html’});
res.end(‘Hello, world! [helloworld sample; iisnode version is ‘
+ process.env.IISNODE_VERSION + ‘, node version is ‘ + process.version + ‘]’);

In web.config enter the following to tell ASP.net to use the Node module we have just installed:


<add name=”iisnode” path=”test.js” verb=”*” modules=”iisnode” />


That’s it you should now be able to view the node server running on your site by going to an address similar to the following:


My site displays the following text:

Hello, world! [helloworld sample; iisnode version is 0.1.14, node version is v0.6.9]

That’s the set-up basics – there are heaps of extension libraries for Node that you should check out at http://search.npmjs.org/ and IISNode contains several samples that can be installed by going to: %programfiles%\iisnode\setupsamples.bat

Next why would you actually want to do this? 🙂




IOS5 disables cookies

Over the weekend one of my colleagues (thanks Neil!) reported that a mobile site we developed was not working properly for him although strangely was functioning fine on his girlfriends phone.

I was unable to recreate the issue on various i-devices I had so I wondered if it was some caching issue so got the user to clear his cache.

What it turned out to be however was that after upgrading to IOS 5 Safari’s cookie settings get changed to never accept cookies (sometimes!). This is obviously going to stop a lot of sites from working properly (including anything that uses session as this is maintained through a cookie).

I can’t find any official release notes/bug report detailing this but have found countless posts indicating that this occurs e.g.:



My recommendation?

You dont have a lot of choice really but to add a bit of script that attempts to set a cookie and warn the user if it cant that cookies have been disabled and provide some instructions about how to re-enable them.

ASP.net sites could look at enabling cookie-less sessions.

In IOS5 cookies can be enabled by going to Settings, Safari, Accept Cookies and change to Always.

Android device on jQueryMobile submitting form on return

We recently had an issue confined to Android users in our jQuery mobile application. When users  pressed the return button on an input field the page was submitted to the server. On every other page pressing the return button would instead correctly call the default action of the page.

The Android return button is a little strange and doesn’t have a key code associated with it. The solution was instead to interupt the form submit event:

if (navigator.userAgent.toLowerCase().indexOf(“android”) > -1) {

$(“#myForm).submit(function () {
return false;

IE 9 and measuring web page performance using window.performance

When optimizing web pages it is useful to measure how long various functions and events take to occur on a page so you can be sure you are appended pictures of your Cat to the DOM as quick as possible.

However it’s actually quite difficult to measure the time various functions and events take to run. Most current methods of measuring time involve getting the current time at various points on a page and then performing simple date arithmetic. However even measuring this way can of course skew the test results (although it should be fairly consistent). Additionally John Resig wrote an interesting post after he discovered some browsers only update their system times around every 15ms (http://ejohn.org/blog/accuracy-of-javascript-time/) so using this method means that you are not going to see micro changes anyway.

The W3c has proposed a standard API for measuring performance (you can read it here: http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html). This isnt actually finished yet so expect there to be a few changes.

We can play with this new api in IE9 (Chrome and the latest stable of Firefox dont seem to support this yet).

To use the new API we retrieve the  window.performance.timing object (note some tutorials such as http://blogs.msdn.com/b/ie/archive/2010/06/28/measuring-web-page-performance.aspx still refer to this as windows.msPerformance but a quick walk of the window object will show we know better..).

The below example shows the syntax:

var timingObj = window.performance.timing;
var navStartTime = new Date(timingObj.navigationStart);

Currently the documentation around some of these properties is a little scarce and its a bit confusing as to what each are actually measuring so I will follow this up as I discover more.