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?
1 Like
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) ā¦
1 Like
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)
1 Like
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.
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ā¦
1 Like