</handlers>
<rewrite>
<rules>
<rule name=”all”>
<match url=”/*” />
<action type=”Rewrite” url=”launch/www” />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
在IIS管理器中重启站点后再次访问，终于运行起来了，不容易啊！不过还是高兴得太早了。
在测试程序功能的过程中，竟然发现获取到的IP为空。在Express框架中，IP是通过req.ip获取的，而req.ip又是从请求头的REMOTE_ADDR获取值。通过一段简单的测试代码，发现REMOTE_ADDR的值也为空。很明显，从IIS到Node.js的过程中，这段头信息丢失了。Google一番之后，发现iisnode确有此问题，官方提供的解决方案是使用X-Forword-For，不过我又发现了另外一个办法。
Web.config中有一段配置（加到</system.webServer>前）可以保留REMOTE_ADDR：
<iisnode promoteServerVars=”REMOTE_ADDR” />
根据说明，保留的REMOTE_ADDR会被改名为x-iisnode-REMOTE_ADDR，所以还得把req.ip的值覆盖一次，在Express的app.js中增加一个中间件函数：
app.use(function(req, res, next) {
req.ip = req.headers[‘x-iisnode-REMOTE_ADDR’];
next();
});
然而，这样调整后，获取到的IP还是空，这不免让人怀疑，req.ip的赋值是不是失败了。看一下Express的源代码可以发现，req.ip是通过define getter的方式定义的，所以要覆盖它就得再define一次：
app.use(function(req, res, next) {
Object.defineProperty(req, ‘ip’, {
get: function() { return this.headers[‘x-iisnode-REMOTE_ADDR’]; }
});
next();
});
这样问题终于解决了，但这不是一个好方法，要是以后Express把req.ip设成只读就麻烦了。
继续测试，又发现另外一个问题。正常来说，博客后台的文件上传功能会把文件传到public/upload这个目录下，但实际上却在launch目录（即原来的bin目录）下生成了public/upload文件夹。其实原因是作为程序入口的www文件是在launch目录下，所以launch目录成了应用程序的执行目录。我的解决办法是，把launch目录的名字改回bin，在根目录下创建一个launch.js去调用bin/www：
