New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node-Inspector Errors #54

Open
thamera opened this Issue Jul 9, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@thamera

thamera commented Jul 9, 2018

Can't see what I am doing wrong but for the life of me, cannot get the debugging to work. Site runs fine. Running IIS 8. Made sure my app pool account has rights to the application folder is inetpub.
Web config shown below. When I run the debugger, I get a bunch of "Unexpected identifier" syntax errors in chrome console. Files getting these error changes every time I refresh. Last error states websocket connection failed during handshake. Anyone have an ideas?

    <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
      <match url="app.js\/debug[\/]?" />
    </rule>
    
    <rule name="StaticContent">
      <action type="Rewrite" url="public{REQUEST_URI}" />
    </rule>        
    
    <rule name="myapp" patternSyntax="Wildcard">
      <match url="*" negate="false" />
      <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True" />
      </conditions>
      <action type="Rewrite" url="app.js" />
    </rule>
    
  </rules>
</rewrite>
<caching>
    <profiles>
        <add extension=".js" policy="DisableCache" kernelCachePolicy="DisableCache" />
    </profiles>
</caching>
<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<security>
  <requestFiltering>
    <hiddenSegments>
      <remove segment="bin"/>
    </hiddenSegments>
  </requestFiltering>
</security>
<httpErrors existingResponse="PassThrough" />
@mattezell

This comment has been minimized.

Show comment
Hide comment
@mattezell

mattezell Sep 20, 2018

Same issue here - and apparently one that a lot of people are having now (plenty of reports in the original repo which is seemingly abandoned)... I am experiencing this on Windows 7 and Windows Server 2016 (with and without websockets enabled).

I can't quite fathom how Microsoft continues to push NodeJS as suitable for Enterprise development when the backbone of NodeJS support in Windows is IISNode. Really regretting spending the last 2 weeks writing this API in NodeJS under the assumption that Microsoft wouldn't be pushing using this unless it was stable, well documented, and well supported (none of which is true in this repo or the original one).

Unfortunately, it's unlikely that anyone will stumble upon this thread until they've already invested in this solution and then encountered problems... But if you're a lucky soul and you do find yourself here before writing your APIs with the plan of targeting Windows, I would advise you do a bit more research and question yourself on if you're making the right decision... I'm betting that most folks who have found their self wading through the issues here and in the original repo would say "NO".

mattezell commented Sep 20, 2018

Same issue here - and apparently one that a lot of people are having now (plenty of reports in the original repo which is seemingly abandoned)... I am experiencing this on Windows 7 and Windows Server 2016 (with and without websockets enabled).

I can't quite fathom how Microsoft continues to push NodeJS as suitable for Enterprise development when the backbone of NodeJS support in Windows is IISNode. Really regretting spending the last 2 weeks writing this API in NodeJS under the assumption that Microsoft wouldn't be pushing using this unless it was stable, well documented, and well supported (none of which is true in this repo or the original one).

Unfortunately, it's unlikely that anyone will stumble upon this thread until they've already invested in this solution and then encountered problems... But if you're a lucky soul and you do find yourself here before writing your APIs with the plan of targeting Windows, I would advise you do a bit more research and question yourself on if you're making the right decision... I'm betting that most folks who have found their self wading through the issues here and in the original repo would say "NO".

@mattezell

This comment has been minimized.

Show comment
Hide comment
@mattezell

mattezell Sep 21, 2018

I wanted to come back and share my small victory in the case that it helps anyone else... I could never get the official debugging to work, but I do have full debugging through VSCode currently.

To get debugging setup in VSCode, you need to modify your iisnode.yml and also add a new configuration to your launch.json.

In your iisnode.yml (or web.config), set the 'nodeProcessCommandLine' so that it includes '--inspect'. So for me, I have:
nodeProcessCommandLine: "c:\\Program Files\\nodejs\\node.exe" --inspect

Next, in your launch.json, add a new configuration to Attach to Remove. So mine looks like this:
... "configurations": [ { "type": "node", "request": "attach", "name": "Attach to Remote", "address": "127.0.0.1", "port": 9229, "localRoot": "c:\\api\\", "remoteRoot": "c:\\api\\" },...
In the above excerpt, localRoot and remoteRoot point to where I've deployed my NestJS Express API (so TS that's been transpiled to JS).

After getting everything setup, you can click on the debug tab on the left of VSCode. Then you select your "Attach to Remote" configuration from the dropdown at the top right of VSCode. Lastly, hit F5 or press the play icon next to your selected config.

Using this approach, I have been successfully able to debug my Express application hosted in IIS using IISNode.

mattezell commented Sep 21, 2018

I wanted to come back and share my small victory in the case that it helps anyone else... I could never get the official debugging to work, but I do have full debugging through VSCode currently.

To get debugging setup in VSCode, you need to modify your iisnode.yml and also add a new configuration to your launch.json.

In your iisnode.yml (or web.config), set the 'nodeProcessCommandLine' so that it includes '--inspect'. So for me, I have:
nodeProcessCommandLine: "c:\\Program Files\\nodejs\\node.exe" --inspect

Next, in your launch.json, add a new configuration to Attach to Remove. So mine looks like this:
... "configurations": [ { "type": "node", "request": "attach", "name": "Attach to Remote", "address": "127.0.0.1", "port": 9229, "localRoot": "c:\\api\\", "remoteRoot": "c:\\api\\" },...
In the above excerpt, localRoot and remoteRoot point to where I've deployed my NestJS Express API (so TS that's been transpiled to JS).

After getting everything setup, you can click on the debug tab on the left of VSCode. Then you select your "Attach to Remote" configuration from the dropdown at the top right of VSCode. Lastly, hit F5 or press the play icon next to your selected config.

Using this approach, I have been successfully able to debug my Express application hosted in IIS using IISNode.

@e-dot

This comment has been minimized.

Show comment
Hide comment
@e-dot

e-dot Sep 28, 2018

Thanks a million!

I was trying to setup iisnode debugging with Visual Studio Code and couldn't make it work (documentation is largely outdated...).

The key thing : adding parameter --inspect when calling the node.exe !!!

Best Regards,

E.

e-dot commented Sep 28, 2018

Thanks a million!

I was trying to setup iisnode debugging with Visual Studio Code and couldn't make it work (documentation is largely outdated...).

The key thing : adding parameter --inspect when calling the node.exe !!!

Best Regards,

E.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment