Scott Hanselman

Visual Studio 2015 - Fixing "Dependencies npm not installed" from fsevents with node on Windows

August 14, '16 Comments [26] Posted in ASP.NET | nodejs
Sponsored By

Maria and I were doing some work together on Thursday and I did a clone of one of her ASP.NET Core repositories and opened it in Visual Studio 2015 Community Edition on my local machine. Some of the JavaScript tool libraries didn't load so I went back into Solution Explorer to see if there was a problem and I saw this weird error that said (or at least, I read it as) "npm not installed."


That's weird, since I have npm installed. I dropped out to the command line and ran:

C:\Users\scott>npm --version

I also ran "where" to see where (and how many) npm was installed. Side note: WHERE is super useful and not used as often as it should be by y'all.

C:\Users\scott>where npm
C:\Program Files\nodejs\npm
C:\Program Files\nodejs\npm.cmd

This looks OK as two of those npms are shell scripts and not run on Windows. Just to make sure you have the version of npm you want, Felix made a VERY useful npm-windows-upgrade utility that you run like this, ironically with npm.

npm install --global --production npm-windows-upgrade

I've used this tool many times with success. It also lets you choose the exact version you want and it's very smart.

However, then I realized that Visual Studio wasn't saying that npm wasn't installed, it was saying a dependency in the npm tree below wasn't installed. That hyphen - is intended to mean something. For the record, I think this is not intuitive and is a poor UX. Perhaps it should say "package(s) not installed" but you get the idea now.

I started manually opening the tree up one item at a time looking for the bad package - while quietly swearing to myself - until I realized that the Solution Explorer tree nodes are searchable.


This is UX issue number two, for me. I think the "broken" library should also include the BANG (!) or warning icon over it. Regardless, now I know I can quickly do a string search.

So what's up with the fsevents library?

I can check the Visual Studio Output Window and I see this:

npm WARN install Couldn't install optional dependency: Unsupported
npm WARN EPACKAGEJSON No description

I dropped out to the command prompt into to the project's folder and run "npm ls" to see an ASCII tree that effectively is the same tree you see in Visual Studio. Note the screenshot with the ASCII tree below.

The output of "npm ls" is a nice ASCII tree

What's that "UNMET OPTIONAL DEPENDENCY?" for fsevents?

Looks like fsevents is a package that is only used on OSX, so it's an optional dependency that in the case of Windows is "unmet." It's a WARNING, of sorts. Perhaps it's more an "INFO" or perhaps, one could argue, it doesn't need to be shown at all on Windows.

A quick google shows that, well, the entire world is asking the same thing. So much so that it got pretty heated in this GitHub Issue asking a similar question.

Regardless, it seems to me that something inside Visual Studio really doesn't appreciate that warning/info/notOKness and says, "hey it's not installed." The part that is missing is that, well, it doesn't need to be installed, so Visual Studio should relax.

A Fix

Here's where it gets super interesting. Visual Studio (consider it from their point of view) needs to keep things consistent so it tests with, and ships with, a version of npm.

I can check that like this:

C:\>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\npm.cmd" --version

Again, this makes sense. That way when working in a large group we can all be sure we're on the same version of stuff. When you get a new version of the Web Tools for Visual Studio, presumably this version of npm gets updated. This also means that unless you tell Visual Studio otherwise, the npm and node you get when running a build in VS is gonna be different than if you do it outside - if you stick with the default settings.

Fear not. It's easily updated. I went over to Tools | Option in Visual Studio:

Tools | Options | External Web Tools has its own list of node copies, and it doesn't include mine

See the Web\External there? I added my node installation like this and made sure it was at the top.

Tools | Options | External Web Tools has its own list of node copies, and I have ADDED my path now.

Then I right click on npm and Restore Packages and all is right with the world as now I'm using npm 3.10.5 rather than 3.3.4.

There are no npm errors anymore

The Output Window for 3.10.5 shows this different output, which apparently stresses Visual Studio out less than npm 3.3.4. (Actually I think VS is calling an npm library, rather than shelling out and parsing the "npm ls --json" payload, but you get the idea.)

npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.14

Adding my global npm/node folder fixes this issue for me and I can move on.

The Weird

BUT. In my fix I'm using npm globally - it's in my %PATH%. The change I made affects all Visual Studio projects on my machine, forever.

Maybe I need to be smarter? Maybe Visual Studio is already being smart. Note the second option there in the list? It's pointing to .\node_modules\bin. That's a LOCAL node-modules folder, right? Ah, I can just add specific version of npm to packages.json there if need be on a project by project basis without affecting my entire system OR changing my Visual Studio settings, right?

However, when I run my build, it's ignoring my project's locally installed npm!

PATH=.\node_modules\.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\npm.CMD" install
npm WARN install Couldn't install optional dependency: Unsupported
npm WARN EPACKAGEJSON No description
npm WARN EPACKAGEJSON No repository field.
npm WARN EPACKAGEJSON No license field.

How can I be sure it's ignoring that relative path? I can temporarily hardcode my local node_modules, like this. Note the PATH *and* the newer output. And it works.

PATH=D:\github\sample-NerdDinner\NerdDinner.Web\node_modules\.bin;node_modules\.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git
"D:\github\sample-NerdDinner\NerdDinner.Web\node_modules\.bin\npm.CMD" install
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.14
npm WARN No description
npm WARN No repository field.
npm WARN No license field.

In this screenshot below I have npm 3.10.6 installed in my project, locally, but it's not being used by Visual Studio if the path remains relative.

I am 99% sure that the relative path ".\node_modules\.bin" that's prepended to the PATH above either isn't being used OR is interfering in some way.

Am I misunderstanding how it should work? Perhaps I don't understand npm enough?


I'm going to continue to dig into this and I'll update this post when I have an answer. For now, I have a fix given my globally installed npm.

I've also passed my feedback/bug report onto the Visual Studio team in the form of an email with a link to this blog post. I hope this helps someone!

Sponsor: Big thanks to Redgate for sponsoring the feed this week. Could you deploy 1,000 databases?Imagine working in a 70-strong IT team, with 91 applications and 1,000+ databases. Now imagine deployment time. It’s not fiction, it’s fact. Read FlexiGroup's story.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

UPDATED for 2015: How to install the nodejs Ghost blog software on Azure Web Apps (and the Deploy to Azure Button)

April 20, '15 Comments [9] Posted in Blogging | nodejs | Open Source
Sponsored By

What? Didn't I blog about this before? Yes, in fact, in 2013 I did an article showing how to get Ghost - a lovely nodejs-based blogging app - running on Azure.  The instructions involved making some changes to Ghost itself to make it friendlier to Azure and doing a git deploy. Since this post both Ghost AND Azure have become friendlier. ;)

Fast forward two years and the instructions have changed! In fact, they've gotten WAY easier. You can still theoretically follow most of my old instructions, but these new ones are WAY better, so just do it this way.


There's a "Deploy to Azure" button up at that you can get an put in YOUR GitHub project's so folks can easily and quickly deploy your app as well!

Here's what you do. Head over to the GitHub repository for Ghost Azure. Click Deploy to Azure. That will automatically install Ghost for you in Azure.

The Deploy to Azure Button

The website will look at the repository from the HTTP Referer header. You'll end up with a nice form like this.

DO make sure to double check your settings, the Site Location is alphabetical right now, and you may not want your blog in Brazil. ;)


Hit Next, then check the summary that will warn you what's getting created, then hit Deploy. Boom. Azure will actually run through the template and setup Ghost (or whatever app you wanted) automatically.

  • Note it's setting it up from Source Control as well, although you can certainly change this. For example, you might want to Fork it yourself, and then Deploy.
  • However, as this is set up today, you won't get updates until you go to Deployments within the Azure Portal and click Sync. You decide if you want the app to update when new code is committed.

After it's created, you can manage your site in the Azure Portal. I made a little free one for this example, as can you if you like.

Ghost in the Azure Portal

And it works just great!

Ghost running on Azure

It's not super obvious what to do next. You'll need click the little chevron there, or visit something like /admin, and you'll get redirected to the Ghost setup process online.


Now you can start your first post!

My first post in Ghost

What's going on here?

Felix Rieseberg added a few files to Ghost and has the fork up here on GitHub. The most interesting one is the AzureDeploy.json. This is an Azure Resource Manager template. Here's another simple example from Elliot Hamai for an ASP.NET MVP app. This file tells Azure (and the Deploy to Azure button) what kinds of things it needs to create and actually gives the system enough information to build a whole form for you!

Maybe this is the perfect time for you to start your own blog! Perhaps you've been putting it off. Go check out my FREE two-hour documentary movie with Rob Conery called Get Involved in Tech! We will get you ready to jump into the world of Social Software Development.

Here's a video of Elliot and I talking about the Deploy to Azure button on Azure Friday. Here's Elliot's blog announcing Deploy to Azure and explaining more.

Remember that Ghost is open source and you can learn more at!

DON'T WANT TO SIGN UP FOR AZURE? You can try Azure out for an hour without signing up for anything. Check out You can make a PHP, Java, nodejs, Python, ASP.NET web app, or even setup Ghost itself. You can also try out Visual Studio online, which is basically a complete IDE in your browser written entirely in JavaScript.

Sponsor: Big thanks to our friends at Raygun for sponsoring the feed this week. I use Raygun myself and I encourage you to explore their stuff, it's really something special. Get full stack error reporting with Raygun! Detect and diagnose problems across your entire application. Raygun supports every major programming language and platform - Try Raygun FREE!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Enabling Websockets for Node apps on Microsoft Azure

November 3, '14 Comments [13] Posted in Azure | Diabetes | nodejs | Open Source
Sponsored By

Whoa my Blood Sugar is a CGM in the Cloud!NOTE: This is a technical post, I'll blog more about Nightscout later this week. Subscribe and watch for my take, or visit

I'm running an application called Nightscout that is a node app with a MongoDB backend that presents a JSON endpoint for a diabetic's blood sugar data. I use my Dexcom G4 CGM (Continuous Glucose Meter) connected with a micro-USB OTG cable to an Android phone. An Android app bridges the device and POSTs up to the website.

Azure is well suited to run an app like this for a few reasons. Node works great on Azure, MongoLabs is setup in the Azure Store and has a free sandbox, Azure supports WebSockets, and * has a wildcard SSL cert, so I could force SSL.

Enabling Websockets and Forcing SSL

So my goal here is to do two things, make sure Websockets/ is enabled in my app because it's been using polling, and force my app to use SSL.

Setting up a node.js site on Azure is very easy. You can see a 3 minute video on how to do a Git Deploy of a node app here. Azure will see that there's a app.js or server.js and do the right thing.

However, because IIS and node are working together to host the site (IIS hands off to node using a thing called, wait for it, iisnode) you should be aware of the interactions.

There's a default web.config that will be created with any node app, but if you want to custom stuff like rewrites, or websockets, you should make a custom web.config. First, you'll need to start from the web.config that Azure creates.

Related Link:  Using a custom web.config for Node apps

Let's explore this web.config so we understand what's it's doing so we can enable Websockets in my app. Also, note that even though our project has this web.config in our source repository, the app still works on node locally or hosts like Heroku because it's ignored outside Azure/IIS.

  • Note that we say "webSocket enabled=false" in this web.config. This is confusing, but makes sense when you realize we're saying "disable Websockets in IIS and let node (or whomever) downstream handle it"
  • Note in the iisnode line you'll put path="server.js" or app.js or whatever. Server.js appears again under Dynamic Content to ensure node does the work.
  • I added NodeInspector so I can do live node.js debugging from Chrome to Azure.
  • Optionally (at the bottom) you can tell IIS/Azure to watch *.js files and restart the website if they change.
  • We also change the special handling of the bin folder. It's not special in the node world as it is in ASP.NET/IIS.
<?xml version="1.0" encoding="utf-8"?>
This configuration file is required if iisnode is used to run node processes behind
IIS or IIS Express. For more information, visit:

<!-- Visit for more information on WebSocket support -->
<webSocket enabled="false" />
<!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
<add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
<!-- Do not interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^server.js\/debug[\/]?" />

<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>

<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
<action type="Rewrite" url="server.js"/>

<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<remove segment="bin"/>

<!-- Make sure error responses are left untouched -->
<httpErrors existingResponse="PassThrough" />

You can control how Node is hosted within IIS using the following options:
* watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
* node_env: will be propagated to node as NODE_ENV environment variable
* debuggingEnabled - controls whether the built-in debugger is enabled

See for a full list of options
<!--<iisnode watchedFiles="web.config;*.js"/>-->

Next, turn on Websockets support for your Azure Website from the configure tab within the Azure Portal:

Turn on Websockets in the Azure Portal

Now I need to make sure the node app that is using is actually asking for Websockets. I did this work on my fork of the app.

io.configure(function () {
- io.set('transports', ['xhr-polling']);
+ io.set('transports', ['websocket','xhr-polling']);

It turns out the original author only put in one option for to try. I personally prefer to give it the whole list for maximum compatibility, but in this case, we clearly need Websockets first. When will Websockets fall back if it's unavailable? What Azure website pricing plans support WebSockets?

  • Free Azure Websites plans support just 5 concurrent websockets connections. They're free. The 6th connection will get a 503 and subsequent connections will fallback to long polling. If you're doing anything serious, do it in Shared or above, it's not expensive.
  • Shared Plans support 35 concurrent websockets connections, Basic is 350, and Standard is unlimited.

You'll usually want to use SSL when using Websockets if you can, especially if you are behind a proxy as some aggressive proxies will strip out headers they don't know, like the Upgrade header as you switch from HTTP to Websockets.

However, even free Azure websites support SSL under the * domain, so doing development or running a small site like this one gets free SSL.

I can force it by adding this rule to my web.config, under <system.webServer>/<rewrite>/<rules/>:

<rule name="Force redirect to https">
<match url="(.*)"/>
<add input="{HTTP_HOST}" pattern=".+\.azurewebsites\.net$" />
<add input="{HTTPS}" pattern="Off"/>
<add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}"/>

Note the pattern in this case is specific to, and will take any Azure website on the default domain and force SSL. You can change this for your domain if you ike, of course, assuming you have an SSL cert. It's a nice feature though, and a helpful improvement for our diabetes app.

I can confirm using F12 tools that we switched to WebSockets and SSL nicely.


The whole operation took about 15 minutes and was a nice compatible change. I hope this helps you out if you're putting node.js apps on Azure like I am!

Sponsor: Big thanks to Aspose for sponsoring the feed this week! Working with Files? Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and many other formats in your applications. Start a free trial today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

"It's just a software issue"- Edge.js brings Node and .NET together on three platforms

April 30, '14 Comments [44] Posted in Learning .NET | nodejs | Open Source
Sponsored By
.NET and node together on three platforms

There was an engineer I used to work with who always said "That's just a software issue." No matter how complex the issue, no matter how daunting, they were confident it could be solved with software.

.NET and C# and NuGet and the community have been making some amazing stuff in the last few years like ScriptCS, Chocolately, Boxstarter. Azure Websites now supports ASP.NET, sure, but also PHP, Python, Java (Tomcat or Jetty or your own container), and node.js. Getting these things to work together has been an interesting software issue. Apps can run side-by-side, but they can't really talk to each other in-process. (Mostly one just moves data between universes over JSON and HTTP when need-be.)

However, Tomasz Janczuk has been working on Edge.js (on Github) for a while now. I showed his work at jQuery Portland last year, but this week he's taking it to the next level. He is creating a wormhole between software universes.

Edge.js now lets you run node.js and .NET code in-process on Windows, Mac, and Linux.

The name is great. An edge connects two nodes, and Edge.js is that edge.

node and .NET connected by edge.js

Here's a node app hello world node app calling .NET. Don't sweat that the .NET code is tunneled inside a comment, this is the Hello World proof of concept.

var edge = require('edge');

var helloWorld = edge.func(function () {/*
async (input) => {
return ".NET Welcomes " + input.ToString();

helloWorld('JavaScript', function (error, result) {
if (error) throw error;

Perhaps you have a bunch of CPU intensive work or algorithms in C#, but you've also got a node.js app that needs the result of that work. Edge can help with that.

You can bring in a CS or CSX file into node like this:

var myCSharpCode = edge.func(require('path').join(__dirname, 'myCSharpCode.csx'));

You can bring code from a .NET DLL into a node.js compiled as well.

var clrMethod = edge.func({
assemblyFile: 'My.Edge.Samples.dll',
typeName: 'Samples.FooBar.MyType',
methodName: 'MyMethod'

It's not a hack, it's a clear way to marshal between CLR threads and the V8 (the node Javascript engine) thread. It's also interesting from a comp-sci perspective as the CLR can have many threads and V8 has the one.


Here's Tomasz's own words:

Edge.js provides an asynchronous, in-process mechanism for interoperability between Node.js and .NET.

You can use this mechanism to:

  • access MS SQL from Node.js using ADO.NET more...
  • use CLR multi-threading from Node.js for CPU intensive work more...
  • write native extensions to Node.js in C# instead of C/C++
  • intergate existing .NET components into Node.js applications

Read more about the background and motivations of the project here.

Now, you might ask yourself, what problem does Edge.js solve? The answer is in the Edge.js FAQ.

Go explore what you can do. Edge goes much further than just C# and Node. It works on Windows, OSX, and Ubuntu but you should just "npm install edge" as there's a node package available.

Have fun! You have a lot more power and flexibility than you think. It's just a software problem.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web

Introducing node.js Tools for Visual Studio

November 21, '13 Comments [93] Posted in nodejs | Open Source | VS2013
Sponsored By
node.js and Express running in VS

Just when you thought it couldn't be crazier in Redmond, today they are introducing node.js Tools for Visual Studio!

NTVS runs inside VS2012 or VS2013. Some node.js enthusiasts had forked PTVS and begun some spikes of node tools for VS. At the same time the PTVS team was also working on node.js integration, so they all joined forces and made NTVS a community project. NTVS was developed by the same team that brought you PTVS with help from friends like Bart Read from Red Gate (he did the npm GUI), and Dmitry Tretyakov from Clickberry for several debugger fixes & features.

NTVS is open source from the start, and has taken contributions from the very start. It supports Editing, Intellisense, Profiling, npm, Debugging both locally and remotely (while running the server on Windows/MacOS/Linux), as well publishing to Azure Web Sites and Cloud Service.

It's actually pretty freaking amazing how they did it, so I encourage you to download it and give it a try because some of the stuff (even given this is an alpha) is very very clever.

Blank Express Application

Node.js Tools for Visual Studio takes advantage of V8 Profiling API's as well Visual Studio's Reporting features to give you a sense of where your program is spending its time.

NOTE: See that File | New Project dialog up there? Visual Studio organizes things by language, so node.js is under JavaScript. But you've also got Python and Django, iOS and Android via C#, TypeScript, VB, F#, all in Visual Studio.

One of the things that's impressed me about the way they integrated node.js into Visual Studio was that they didn't try to recreate or re-do things that already worked well. It's node, it runs node.exe, it uses the V8 debugger, it uses the V8 profiler because that's what people use. Duh. But, for example, NTVS can take the output from the V8 profiler and display it using the Visual Studio Profiler Reporting Tools. No need to reinvent the wheel, just use the right tool for the job.

Hacking on the Ghost blogging engine with node.js for Visual Studio

Let's look at an example.

From within Visual Studio, go File New Project, click JavaScript, then "From Existing Node.js code."

From Existing node.js Code

Point NTVS to your Ghost folder.

Create from Existing Code

Then tell node.js for VS that the startup file is index.js, hit Next, save the project file and Finish.

Create New Project from Existing Code

At this point, you've got Ghost inside VS.

Random: that since I have Web Essentials I also get a nice split-screen markdown editor as well.

From here, just hit F5 to Debug, or Ctrl-F5 to start without Debugging. Also notice the properties of the Project in the lower right corner there showing the node path and port as well as the Startup File. You can change these, of course.

Ghost inside Visual Studio with NTVS

Here's me running Ghost locally. You can see the path to node, the ghost.js file and my browser.

Running Ghost in VS with node for VS

You'll get good intellisense for completions and help for method signatures.

Intellisense example


Node.js Tools for Visual Studio includes complete support for debugging node apps. This includes support for Stepping, Breakpoints, "Break on exception", as well as Locals, Watch, Immediate and Call Stack tool windows.

You can manage Exceptions just like any other language service. See in the dialog below node.js exceptions are listed along with other exceptions in managed and unmanaged code.

Managing Exceptions in node.js for Visual Studio

The debugging still happens like it always has, with the node V8 debugger, except Visual Studio connects to the debugger over another socket (remember, you can even debug node.js remotely running on a Linux or Mac like this!) and translates how V8 thinks into how Visual Studio thinks about debugging. The experience is seamless.

See in this screenshot, you can see node.exe is being debugged, I'm running Ghost. You can see my Call Stack, and the Locals in the Watch Window. I can inspect variables, step around and do everything you'd want to do when debugging a Web App.

Debugging Session of Ghost in VS with Node Tools for Visual Studio

npmVisual Studio

The npm experience is pretty cool as well. Node.js for Visual Studio is always watching the file system so are more than welcome to run npm from the command line or from within the node immediate window and Visual Studio will see the changes.

You can also use the npm Package Management dialog and search the repository and install packages graphically. It's up to you.

npm package management within VS

Here's a package installing...

Installing a module

The physical node_modules and how modules are handled is pure node...VS doesn't touch it or care. However, the Solution Explorer in Visual Studio also presents a logical view on top of the physical view.


NOTE: I really like this. I think it has potential and I'd even like to see references in .NET treated like this. The physical and the logical, along with a dependency tree showing NuGet packages. It helped me understand the project much better.

There's lots more. There's an REPL interactive window, and you can just publish like any other web project using the same Publish Wizard that ASP.NET projects use. You can publish node.js apps directly to Azure as well, either with Git or with Visual Studio publishing.

You can also remotely debug node instances running on other machines by starting node with the included Remote Debugging Proxy.


node.exe RemoteDebug.js -machineport 5860 script.js

As mentioned, you can do remote debugging between Visual Studio and node running on any server OS.


I'm personally pretty happy with the way that Visual Studio is turning (in a short amount of time, seems to me) into quite the competent language and environment factory.

Node.js Tools for Visual Studio is entirely open source under the Apache license and they welcome contributions and bug reports. It's Alpha and it's early but it's awesome. Go get it. Big congrats to all involved!

Sponsor: Thanks to Red Gate for sponsoring the feed this week! Easy release management: Deploy your .NET apps, services and SQL Server databases in a single, repeatable process with Red Gate’s Deployment Manager. There’s a free Starter edition, so get started now!

Disclosure: FYI, Red Gate does advertise on this blog, but it was a total coincidence that a Red Gate employee helped with node.js Tools for VS. I just found that out today. They are very nice people.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Page 1 of 2 in the nodejs category Next Page

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.