Thanks @sjmcdowall, that was the crucial information I needed
I was able to use demeteorize with node v6, then I uninstalled v6 and installed v0.10.46. I was able to run the npm install command from the programs/server directory without any errors, and when starting my application with node main.js it just told me I needed to set the environment variables. So after setting those, it started up fine.
I guess we can work around this without too much issue. Our build server can demeteorize with a specific version of node and we can handle deploying the artifact to a system with a more recent version of node.
I guess that when Meteor 1.4 is released and the internal node binary is bumped to v4; as long as our application continues to operate normally after being updated for Meteor 1.4 then we shouldn’t need to continue using node 0.10 for demeteorizer from that point on.
Glad you got it working – and exactly! Once Meteor 1.4 bumps node to V4 it should be easier to deploy since you can use the same node version across the “build” and “execution” parts. Of course, you’ll want to use V6 but maybe that will just work too.
I presume it’s not as easy as using the correct version of node? Since 1.4 you need node 4.X.X whereas before it was 0.10.40.
And yes, I know you can run it from the command line, but that doesn’t mean that it’s the same node binary iisnode is running. Maybe it’s pointing to a 0.10.40 node still?
I just tried that web.config but I get the same error.
Out of interest, do you have a PORT environment variable set? I am wondering if the issue is related to the ports being different between the demeteorized app and the IIS binding. From what I have been reading, iisnode asks that developers use the process.env.PORT variable, but it’s not possible for me to set this for the demeteorized application since it relies on the PORT environment variable. Or is it possible? Just throwing some ideas out there.
process.env.PORT and setting the “PORT environment variable” is the same thing. So when you set a variable in Windows (SET PORT=XXXX) that turns into process.env.PORT within a node application. It’s slightly different for Linux systems, but the idea is the same (export PORT=XXXX for Linux)
Should it matter then that the node application is running on port 8080 and the IIS site binding is port 80? I think I am right in that iisnode should handle the communication between those ports, but I just want to double check.
I would try turning on event tracing to see if you can get some more info about the error. I don’t think this was directly caused by the Meteor upgrade (we are running the latest version without any issues).
I am a total newb when it comes to iisnode (I hadn’t even heard of it let alone use it) … but … one would think that you would have to somehow map the port / URL on IIS to the port (and maybe URL) within the node / meteor application so it knows to go from http://some.domain:80/foo -> meteor iisnode :8080 ??
Also it would be a bit odd to not have iisnode output anything at all to stdout/stderr when things happen? Maybe within iisnode you can specify some log file to use? I think you are close …
Also – isn’t there an “issue” area for iisnode you can post to asking for help? Seems like this is the main issue and not much else…
PORT is set to 8080. If I unset PORT then there is a conflict because the default port binding the node app uses is 80, which is the same as the IIS site, so the node application fails to start.
Seems like a great article to try to debug this, but lo and behold the first thing I get out of here is that PORT should NOT be set at all because it appears iisnode will set the PORT it wants you to listen to create a channel back to it. So I would make sure NO PORT is set anywhere and console.log the process.env.PORT at the start of the node main.js or where ever and see what port # it’s doing … are you sure you are letting iisnode LAUNCH your node application?
Anyway, maybe that article will help – seems useful to me.
