Thursday, January 31, 2013

Paste photos from your phone directly into Windows Live Writer

You are writing a blog post using Windows Live Writer. You want to include a picture you took with your phone. The options you have are many but none of them is simple. You can use USB cable, WiFi synchronization, Bluetooth, DropBox, SkyDrive, or Picasa. Or, if you are like me, you can e-mail the pictures to yourself, save to disk, and then include in your blog.

All this hassle is time consuming and makes you think twice before using pictures from your phone in your blog.

Enter Picture from phone plug-in to Windows Live Writer. The plug-in allows you to “paste” pictures from your phone directly into Windows Live Writer. The process takes only a few seconds and does not require any cables, configuration, third party services, or e-mail. Some call it witchcraft, so brace yourself.

Witchcraft 101

Your experience starts with a new Windows Live Writer blog post about, say, your last vacation. You get to the point where you want to include a picture from your phone:


You go to the “Insert” menu and choose “Picture from phone” (assuming you have installed the Picture from phone plug-in):


A window shows up with a QR code to scan. Scanning instructions are also provided for those new to QR codes:


Your phone must have internet connectivity. It is recommended you enable WiFi to speed up the transfer if you can (after all, you will be sending several MB worth of JPEG content; besides speed you also don’t want this to eat into your data plan). As soon as you scan the QR code with your phone, Windows Live Writer detects that (yes, I know, it is magic):


Meanwhile on your phone your QR scanning software redirects you to your mobile browser and opens a web site that allows you to select and upload your picture:

Screen Shot 2013-02-01 at 12.58.51 PM Screen Shot 2013-02-01 at 12.59.16 PM Screen Shot 2013-02-01 at 12.59.47 PM

And voila! Your picture is now embedded in your blog post:


Witchcraft explained

To get started, you will need a lizard’s tail, four rotten eggs of the greenback turtle collected on the first full moon in April, and a Windows Azure subscription. The last one is easiest to procure for free here. You also need to understand the basics of QR codes, node.js, Windows Azure Blob Storage, and Windows Azure Web Sites.

Here is how you mix it all up. First, when you open the “Picture from phone” plug-in window, a temporary, one-time relay address is registered with a node.js web site hosted in Windows Azure Web Sites. The relay allows messages to be exchanged between devices that know its unique address. The QR code the plug-in displays encodes this one-time relay address. When you scan the QR code with your phone and open the address in the mobile browser, it immediately posts a “hello” message to the relay, which allows the Windows Live Writer on your PC to switch its view and encourage you to choose a picture on the phone. Once you select the picture and upload it to the relay, it is temporarily saved in Windows Azure Blob Storage, and can be referenced there with a unique URL. The URL of the picture is then posted to the relay. When Windows Live Writer receives the message, it fetches the picture from Windows Azure Blob Storage, closes the plug-in window, and includes the picture in the blog post you are editing. The temporary relay address is deleted along with any associated content in the Windows Azure Blob Storage.

So where does the lizard’s tail come in? I just like to keep it handy in case I need it, so save it for some of the future experiments.

Friday, January 4, 2013

Hosting WebSocket apps in IIS using iisnode

In this post I explain how to configure a node.js application to use of WebSockets when hosting it in IIS 8 using iisnode. This complements a recent post in which I showed how to host node.js WebSocket applications in IIS on Windows using iisnode and faye-websocket module.

The complete code of the sample for self-hosting and IIS hosting of and faye-websocket in IIS using iisnode is available at

From Zero to Divine in  Seven Seconds

You need Windows 8 or Windows 2012 machine with IIS 8 and iisnode installed.

Clone the Dante sample, install dependencies, and set up IIS virtual directory pointing to the code of the sample:

git clone
npm install

Then navigate to the sample at http://localhost/dante/server-socketio.js. You should see Dante’s Divine Comedy streamed to you over websockets from a application hosted in IIS 8 using iisnode, one stanza every 2 seconds:


You can see four HTTP requests being made. The first one targets the node.js application server-socketio.js and returns the HTML page with client side JavaScript. The page requests the client library from the server, which is the second HTTP call. Next, the client side JavaScript on the page performs the handshake (3rd HTTP requests). Finally, a WebSocket connection is established and the Dante’s Divine Commedy is streamed from the server as discrete WebSocket messages over that single connection.

Under the hood

Hosting node.js apps in IIS using iisnode requires some extra steps compared to self-hosting such apps. Unlike in a typical self-hosting case, node.js apps hosted in a IIS virtual directory own only a subset of the URL space, and must be adequately configured to that effect. In addition, IIS must be told which requests constitute traffic and must be handled by iisnode as opposed to other built-in IIS handlers (e.g. static file handlers).

This explanation assumes the node.js application is hosted in a IIS virtual directory named ‘dante’ as opposed to the root of an IIS website. The latter case is simpler to configure, with only required changes being the changes in web.config described below.

Below are the key components of the configuration. Full source code of the sample is at


There are three aspects that must be configured in web.config: handler registration, URL rewrite rules, and IIS wesocket module configuraiton.

First, you must inform IIS that the file is a node.js application and must be handled by iisnode. Without this, IIS would try to serve the file as a client side JavaScript using the static file handler:

<add name="iisnode-socketio" path="server-socketio.js" verb="*" modules="iisnode" />

Then, the URL rewrite module must be informed that all HTTP requests that start with the ‘’ segment constitute node.js traffic and should be redirected to the server-socketio.js as the entry point of the node.js application. Without this, IIS would attempt to map these requests to other handlers, and most likely respond with a failure code:

<rule name="LogFile" patternSyntax="ECMAScript">
<match url=""/>
<action type="Rewrite" url="server-socketio.js"/>

Lastly, the built-in WebSocket module that IIS 8 ships with must be turned off, since otherwise it would conflict with the WebSocket implementation provided by on top of the raw HTTP upgrade mechanism node.js and iisnode support:

<webSocket enabled="false" />

The complete web.config is at

The server

The server code must configure to inform it that the node.js application owns just a subset of the URL space as a result of being hosted in IIS virtual directory. This means that traffic that the server normally listens to on the / path is going to arrive at /dante/

io.configure(function() {
io.set('transports', [ 'websocket' ]);
if (process.env.IISNODE_VERSION) {
io.set('resource', '/dante/');

Notice this configuration change in is only made when the application is hosted in IIS; the same code base of the sample can also be self-hosted, in which case the configuration is left unmodified.

The full code of the server is at

The client

The client code must contain configuration change corresponding to the server, otherwise client library would by default assume the traffic should be sent to the / path on the server:

var address = window.location.protocol + '//' +;
var details = {
resource: (window.location.pathname.split('/').slice(0, -1).join('/') + '/').substring(1)

var client = io.connect(address, details);

Notice that this client code works correctly both when the server is self-hosted or hosted in a IIS virtual directory. This is because the configuration sets the URL paths relative to the pathname of the original request that rendered the HTML page. In the self-hosted case, the original page is rendered from http://localhost:8888/, and consequently’s resource property is set to ‘’. In the IIS hosted case, the original request is rendered from http://localhost/dante/server-socketio.js, and as a result the resource property will be set to ‘dante/’. This allows the client code to be agnostic to how the server is hosted.

The full code of the client is at


My Photo
My name is Tomasz Janczuk. I am currently working on my own venture - Mobile Chapters ( Formerly at Microsoft (12 years), focusing on node.js, JavaScript, Windows Azure, and .NET Framework.