Well your main.js program is one level ABOVE the program/server level – which is certainly a bit odd from what I am used to – but again – may have changed in 1.3.
Can you try for fun to go up a folder level to programs level and then do a
node main.js
?? Also – what does the README file at that level say? Maybe there is a hint in there if they changed how things are laid out.
I haven’t tried yet, but I will be trying to get it to work later this week and I will post my results.
I have followed the instructions here but I am facing issues when starting my application with either npm start from the .demeteorized/bundle/program/server directory or node main.js from the .demeteorized/bundle directory.
We are using meteor 1.3.5.1 with Node 6.3.1 (32-bit, was originally using 64-bit but facing too many issues) and demeteorizer 4.0.0.
The error I am seeing when trying to start the app is:
Administrator@DEV-WEB c:\Repos\hub3\.demeteorized\bundle
$ node main.js
C:\Repos\hub3\.demeteorized\bundle\programs\server\node_modules\fibers\future.js:280
throw(ex);
^
Error: Module did not self-register.
at Error (native)
at Object.Module._extensions..node (module.js:568:18)
at Module.load (module.js:458:32)
at Module.Mp.load (C:\Repos\hub3\.demeteorized\bundle\programs\server\npm\node_modules\meteor\babel-compiler\node_modules\reify\node\runtime.js:16:23)
at tryModuleLoad (module.js:417:12)
at Function.Module._load (module.js:409:3)
at Module.require (module.js:468:17)
at require (internal/module.js:20:19)
at bindings (C:\Repos\hub3\.demeteorized\bundle\programs\server\npm\node_modules\meteor\npm-bcrypt\node_modules\bcrypt\node_modules\bindings\bindings.js:76:44)
at Object.<anonymous> (C:\Repos\hub3\.demeteorized\bundle\programs\server\npm\node_modules\meteor\npm-bcrypt\node_modules\bcrypt\bcrypt.js:3:35)
After some searching around, it seems that the issue may be related to fibers not building correctly for my system. I have been able to do an npm rebuild without issue, and I have also tried removing and installing the fibers package.
When installing or rebuilding, I get a message like this (cut for brevity):
Administrator@DEV-WEB c:\Repos\hub3\.demeteorized\bundle\programs\server
$ npm rebuild
> fibers@1.0.13 install c:\Repos\hub3\.demeteorized\bundle\programs\server\node_modules\ fibers
> node build.js || nodejs build.js
`win32-ia32-v8-5.0` exists; testing
Binary is fine; exiting
...
Is there anything else that I can try to help the application to start?
The first thing is that Meteor is not certified or compatible with Node V6 anything. You MUST use the same version of node as you do in development … which is something like… 0.10.40? Maybe slightly higher … but it’s in that range … and that is the version of node you need to use for the demeteorizer, npm install, etc. etc. etc.
So first step is to make sure your node version – and then – did the npm install actually work?! Output from that would be interesting …
I’ve just rolled Node back from v6 to v0.10.46. But it seems that demeteorizer doesn’t work in Node prior to version 4.
My bad! Sorry – yeah I forgot they updated Demeteorizer to use some new features. Long term this is good but short term it can be a hassle. So – I guess what is needed is when you do the demeteorizer step – use node 4+ but … when you move the resultant code ro wherever to run it – change back to node 0.10.40 for the subsequent steps (npm install and node main.js or whatever) …
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.
Hi,
Could you maybe share what we need to do to deploy to windows with meteor 1.4?
Use the native approach described in the deploy guide from meteor, or use demeteorizer etc?
thank you
Sorry – didn’t see this and my app is still @ Meteor 1.2, so no chance to explore the best method for a 1.4 app. Have you tried to do it?
Hi
No not yet… I was running iT with --production but that is not stable…
Also can we use mupx to deploy from and TO Windows. Specs only say from…?
Verstuurd vanaf mijn iPhone
I’ve tried this since upgrading my project to Meteor 1.4 and I am facing some issues that I am trying to get some answers on:
And I posted on the iisnode GitHub issues site too: https://github.com/tjanczuk/iisnode/issues/528
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 thought I had checked but your message prompted me to check again. I know how easy it is to miss these little things.
It looks like I am using Node v4.5.0 x86, and the web.config is pointing to the correct location for that version of Node also:
<iisnode nodeProcessCommandLine="C:\Program Files (x86)\nodejs\node.exe" />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)
Ah okay, that makes sense.
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.
Yeah, IISNode handles the communication between IIS/Node using a named pipe (this was an issue in the past)
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).
Thanks, I’ve tried enabling ETW logging in IIS if this is what you are referring to? But I am not seeing any additional relevant information.