Visual Studio 2017 - Processus de serveur Node.JS - Désactiver ?

Question

Je travaille sur une application ASP.NET dans Visual Studio 2017 et je remarque qu'un processus Node.JS : Server-side Javascript s'exécute entre 1,3 et 1,8 Go de mémoire. Mon processus de travail IIS a la taille normale qu'il a dans VS 2015.

Mon application n'inclut aucune bibliothèque Node.JS. Je n'arrive pas à trouver comment désactiver ce processus Node.JS : Server-side Javascript. Il consomme trop de mémoire pour quelque chose dont je n'ai pas l'utilité.

Existe-t-il un moyen de supprimer ce problème, à part désinstaller VS 2017 et revenir à VS 2015 ?

Tuer le processus principal dans le gestionnaire des tâches n'affecte rien dans VS, mais si je vais dans l'onglet Détails et que je tue les processus individuels en cours d'exécution, cela fait planter Visual Studio. J'ai pris une vidéo de ce qui s'est passé après avoir tué le processus et lancé ma page web locale (Désolé pour la qualité, le logiciel a limité la taille de l'image à 2MB) :

Answer 1

Outils > Options > Éditeur de texte > JavaScript/TypeScript > Service de langue...

Décochez la case "Activer le nouveau service de langage JavaScript".

Cela semble empêcher le processus NodeJS de démarrer.

Answer 2

J'ai soulevé le feedback sur cette question :

https://developercommunity.visualstudio.com/content/problem/31406/visual-studio-2017-nodejs-server-process-turn-off.html

J'ai reçu une réponse d'une équipe MS - il m'a dirigé vers ce post :

https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html?childToView=27629#comment-27629

Le processus node.exe dispose de la ligne de commande :

En fait, on m'a dit :

Dans VS 2017, plusieurs fonctionnalités sont implémentées en JavaScript. Node.js est utilisé par Visual Studio pour exécuter ce JavaScript. Entre autres choses, Node est utilisé pour exécuter le code qui fournit des services de formatage et d'intellisense lorsqu'un utilisateur modifie TypeScript ou JavaScript. Il s'agit d'un changement par rapport à VS 2015.

Cela répond à ma question, mais en met en lumière une autre - pourquoi avez-vous besoin de 1,4 Go de mémoire pour me donner intellisense sur les fichiers JavaScript ... ou est-ce l'une des solutions qui a été intégrée dans VS afin qu'il utilise moins de mémoire pour ne pas atteindre la limite de 2 Go (4 Go) des processus 32 bits ? Questions questions questions questions.

Answer 3

Vous devez désactiver le support TypeScript sur Visual Studio :

Outils > Extensions et mises à jour > TypeScript pour Microsoft Visual Studio > Désactiver

Après cela, il suffit de redémarrer Visual Studio, et vous êtes prêt à partir.

Answer 4

La réponse de Ryan Ternier m'a orienté dans ce que je crois être la bonne direction. En suivant son lien ( https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html?childToView=27629#comment-27629 ) m'a conduit à la réponse de Bowden Kelly, juste en dessous de la réponse acceptée.

Voici la réponse de Bowden Kelly :

Le processus de nœud que vous voyez est en train d'alimenter le service de langage JavaScript. Vous verrez ce processus apparaître chaque fois que vous modifiez un fichier JS, un fichier TS ou tout autre fichier contenant du JS/TS (html, cshtml, etc.). Ce processus est à l'origine de l'IntelliSense, de la navigation dans le code, du formatage et d'autres fonctions d'édition, et ce en analysant le contexte complet de votre projet. Si vous avez beaucoup de fichiers .js dans votre projet, cela peut devenir important, mais il est plus que probable que le problème est que vous avez beaucoup de fichiers de bibliothèque qui sont analysés. Par défaut, nous analysons chaque fichier .js/.ts de votre projet. Mais vous pouvez remplacer ce comportement et régler le service linguistique pour qu'il se concentre uniquement sur votre code. Pour ce faire, créez un tsconfig.json dans votre projet Root avec les paramètres suivants :

{ "compilerOptions": { "allowJs": true, "noEmit": true }, "exclude": [ "wwwroot/lib" //ignore everything in the lib folder (bootstrap, jquery, etc) // add any other folders with library code here ], "typeAcquisition": { "enable": true, "include": [ "bootstrap", "jquery" //list libraries you are using here ] } }

Une fois que j'ai ajouté le dossier contenant toutes mes bibliothèques script dans le fichier tsconfig.json, la vie était à nouveau belle.

Answer 5

La solution de contournement la plus sale qui soit : renommez simplement le fichier ServiceHub.Host.Node.x86.exe à quelque chose d'autre. Cela ne m'a pas gêné depuis. Quand (si) vous en avez vraiment besoin, il suffit de le renommer.

La même astuce fonctionne dans Adobe Photoshop qui utilise également Node pour une raison que je n'ai pas encore découverte dans mon flux de travail habituel.

---

Il s'avère que...

Vous ne pouvez pas simplement le renommer et espérer que les choses continuent à fonctionner. Qui l'eut cru ?

Apparemment, cette astuce de renommage ne fonctionne que si vous suspendez le processus VS et tuez Node, puis reprenez VS. Si vous essayez de lancer VS avec le fichier exe de Node renommé, il se plantera lors de l'ouverture d'un projet avec une "unknown hard error". De plus, en travaillant sur un projet déjà chargé, le compteur de référence paresseux des méthodes et propriétés ci-dessus ne fonctionnera pas parce qu'apparemment cela dépend de la présence de Node.

Ainsi, il pourrait être acceptable de suspendre le processus Node et de laisser la pagination de Windows échanger sa mémoire de la RAM vers le disque dur, sans renommer l'exe afin de pouvoir relancer le VS plus tard sans avoir à passer par le renommage. Si vous êtes prêt à vivre avec les conséquences, c'est à dire.