I am currently experiencing a strange issue with Node.js within Visual Studio.
I'm currently working on multiple projects (containing many typescript files - i've read elsewhere this could possibly have something to do with my problem) in Visual Studio 2015 (Version 4.7.02053). I have node.js (v 6.10.0) installed on my dev machine also. Currently we are using the built in TypeScript compiler within visual studio (previously using grunt for ts compilation, now just for sass).
I've also configured visual studio to use the current version of node I have installed (please see screenshot below):
Custom Path to node.js installation
My issue is this, whenever I open one of my projects, multiple, I mean a lot, I mean like between 50-100 node.exe processes spin up, please see the image below!
Lot's of node processes, seems to be update-notifier\check.js???
This is eating away at my CPU and rendering my machine barely usable, especially when i have three or four separate projects open at the same time.
I've attempted to google a fix for this but haven't come up with anything that has worked thus far, so, any help you could possibly give me is greatly appreciated.
Thanks in advance,
Paul
This seems to have to do with the update-notifier package.
Related
If I'm in my WSL2 Ubuntu filesystem I can simply navigate to a javascript/nodejs folder and type code . to open that project folder and thanks to VS Code's Remote extensions, I'm essentially remoting into the Linux environment and ready to code.
Now Visual Studio 2022 has been released, I was wondering if it too supports the same level of cross-platform IDE capability as VS Code?
How, for instance, when in my WSL2 Ubuntu project in Windows Terminal, can I open my javascript/nodejs project in the Linux filesystem using VS2022, or is this not supported because VS Code is the only cross-platform IDE that can do this?
So its not really possible to do how your thinking. The problem here is that you your not understanding the difference between a "Code Editor", and an "Integrated Development Environment (IDE)", which is totally understandable, as the line that separates the two has become blurred in recent years, and also a topic of debate. There was a far more explicit distinction between the 2 10-15 years ago, however, Microsoft has done a good job at separating the two, where JetBrains will release a piece of software that can be used as an IDE, but is more often than not, used as an editor, but will still call it an IDE, even though its not an IDE in a pure sense.
How is all this related to your question?
When you open your Node.js project in VSCode via the code . command, you are opening it in an editor that implements Intelli-code, as well as a wealth of other tools, but essentially, the editor, and all the tools extract the names & file extensions of your documents, parse them (usually turning much of the info into an AST, where many extensions will make use of that info to offer the various tooling capabilities/features. The point is at the end of the day, the editor just parses all of your code, gives you info, and you make any changes as needed to your code. And again, this is what your doing with code .
With Visual Studio 2022, you can't open a project with it, unless its a project type the IDE supports, and enables the IDE, to embed its-self into your project. This includes things like built in environment, built in cache, built in build system, the files needed to bootstrap its-self. With an IDE, the IDE is part of the project.
So then why does Visual Stdio 2022 work with Node?
It works with node, to create Node.js applications within a windows environment, and it offers the ability to access different Windows SDK features via Node. These are things you could never do using server-side Linux builds with Node. When you build a Cpp application for windows, you package the entire thing in a .sin file, I haven't built a windows app in node, but I know that Node also uses the .sin file build system, which requires Visual Studio & Windows SDK to do, and parts of Visual Studio/Windows to be embedded into the project, for the project to be able to work in a Windows OS, and take advantage of MS Windows features.
Long story short, V.S. Code is the right tool for what your doing, why would Microsoft invest in two identical tools any way? If you ever want to build something for Windows, or for MS mobile device using Node, you will probably want to change your environment, to VS2022.
I'm a new hololensdeveloper and I recently made a Hololensproject using net scripting backend just because there were way more information on how to set it up and get it working with Visual Studio.
Now when I feel somewhat confident I decided to change it up to il2cpp, but I have a major issue.
Everytime I put a c#script(even empty ones) into any folder within the application the Hololens won't even start it. The screen goes black for some seconds and then returns me to the mainpage.
This feels strange as all the scripts from the HolotoolKit works fine and they are written with c#.
Im currently using
.Unity 2018.3.4f1
.HolotoolKit 2017
.Visual Studio 2017
Thank you!
-----Solved------
SO after alot of time, I switched to Unity LTS and that fixed my problem. Feels bad that I have to rely on an older version.
If I remember correctly, using the HoloToolKit and not the mrtk v1 or v2, you should use Unity LTS 2017. Maybe thats the problem?
And I'm not sure if I understood you the right way. So you are building it in unity and than deploying it to the HoloLens without getting any errors in your console?
Also changing the scripting backend framework, means using a different build directory and If you are not doing that Unity should give you a message like "Build path contains project built with IL2CPP or .Net"
Usually we're in a microsoft stack development but for the project purposes we need to develop in node.js in visual studio 2017.
There are some things we don't understand at all but are quite annoying.
We've installed node.js tools for Visual Studio 2017 but intellisense work for some things and doesn't for others.
2 main problems we're facing:
For example, for some node modules (router, express, etc...) intellisense works fine. For others (mongorito, for examlple, but its not mongorito specific, there are many others also) we don't get any intellisense nor we can navigate through its definitions ('go to definition').
For any file we open we get alot of TSxxx error messages. something like this:
Don't know if its important but with the same setup we had our team members to work on angular 2/4 projects (that use node modules, of course) and everything worked fine.
So, if anyone has a piece of advice we would highly appreciate it. And please explain it like for a complete idiots.
PS.
Don't know if its important, but i must say that solution builds, all tests are good and all runs as it should. Its IDE problem.
So, for everyone having the problem i'll post the solution here.
Problem was in typescript version. Now, that comes with a few details.
In Visual studio pre 15.2 you can't have typescript versions switching. So, i first updated VS to 15.2.
After that, i've installed Typescript SDK with latest typescript (2.4.1. i think at the moment).
Then go to Tools > Options > TextEditor > Javascript/Typescript > Intellisense > Here choose typescript version from the drop down.
[I'll leave answer unaccepted for a bit for the case someone comes with a better solution]
I'm working on an ASP.NET application in Visual Studio 2017, and I'm noticing a "Node.js: Server-side JavaScript" process running at 1.3 GB to 1.8 GB of memory. My IIS worker process is the normal size it is in Visual Studio 2015.
My application doesn't include any Node.js libraries. I'm not able to figure out how to turn this Node.js: Server-side JavaScript process off. It's eating up too much memory for something I have no use for.
Is there a way to kill this apart from uninstalling Visual Studio 2017 and switching back to Visual Studio 2015?
Killing the main process in Task Manager doesn't affect anything in Visual Studio. However, if I go to the Details tab and kill the individual running processes, it crashes Visual Studio. I took a video of what happened after I killed the process and ran my local web page (sorry for the quality; Stack Overflow limited image size to 2 MB):
In menu Tools → Options → Text Editor → JavaScript/TypeScript → Language Service...:
Uncheck 'Enable the new JavaScript language service'.
Restart Visual Studio
This appears to prevent the Node.js process from starting.
I raised feedback on this issue:
Visual Studio 2017 - Node.js Server Process - Turn off?
I got a response back from the Microsoft team - he directed me to this post:
Node.js server-side JavaScript process consuming too much memory
The node.exe process has the command line:
Effectively I was told:
In Visual Studio 2017, several features are implemented in JavaScript. Node.js is used by Visual Studio to run that JavaScript. Among other things, Node is used to run the code that provides formatting and IntelliSense services when a user is editing TypeScript or JavaScript. This is a change from Visual Studio 2015.
You have to disable TypeScript support in Visual Studio:
Menu Tools → Extensions and Updates → TypeScript for Microsoft Visual Studio → Disable.
After that, just restart Visual Studio, and you are good to go.
Ryan Ternier's answer pointed me in what I believe is the right direction. Following his link led me to Bowden Kelly's answer, right beneath the accepted answer.
Here is Bowden Kelly's answer:
The node process you are seeing is powering the JavaScript language service. You will see this process appear anytime you edit a JS file, TS file, or any file with JS/TS inside (html, cshtml, etc). This process is what powers IntelliSense, code navigation, formatting, and other editing features and it does this by analyzing the entire context of your project. If you have a lot of .js files in your project, this can get large, but more than likely the issue is that you have a lot of library files that are being analyzed. By default, we will scan every .js/.ts file in your project. But you can override this behavior and tune the language service to only focus on your code. To do this create a tsconfig.json in your project root with the following settings:
{
"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
]
}
}
Once I added the folder with all my script libraries into the tsconfig.json file, life was good again.
The dirtiest workaround ever: just rename the ServiceHub.Host.Node.x86.exe to something else. It hasn't bothered me since. When (if) you actually need it, just rename it back.
The same trick works in Adobe Photoshop which also runs Node.js for some reason I haven't discovered in my usual workflow yet.
It turns out...
You can't just rename it and expect things to keep working. Who knew!
Apparently this renaming trick only works if you suspend the Visual Studio process, kill Node.js, and then resume Visual Studio. If you try to launch Visual Studio with the Node.js EXE file renamed, it will crash when opening a project with an "unknown hard error".
Also, while working on an already loaded project, the lazy reference counter above methods and properties won't work because apparently that relies on Node.js being there somehow.
So it might be okay to just suspend the Node.js process and let Windows paging swap its memory out from RAM onto the hard drive, without renaming the EXE file, so you could start Visual Studio again later without going through the renaming hassle. If you're willing to live with the consequences, that is.
Something that can help the projects mitigate the Node.js weight is to reassign the node version used under menu Tools → Options → Projects and Solutions → Web Package Management to an installed 64-bit version. Visual Studio will still launch its internal Node.js process for a tsserver.js instance, but any TypeScript code in the project will default to the supplied version -- and this helped me firsthand.
Also, another time I found the language service to be running down, I discovered using a simple tsconfig.json file above the directories used as repositories, and specify to skipLibCheck: true, and add node_modules to exclude—it tremendously helped along the service, and one file does all folders beneath it, regardless of direct project references. P.S.—if you do want JavaScript intellisense support still, make sure to set the allowJs: true and noEmit: true option.
Lastly, verify in the TypeScript Options under the menu Tools → Options → Text Editor → JavaScript/Typescript → Project that it is not checked to Automatically compile TypeScript files which are not part of a project since that can also tie up resources for auxiliary third-party projects using Node.js or TypeScript.
These are not foolproof. Each has to find their exact bottleneck, but I have found these have worked for me and my team more often than not.
I am just noting that the high-memory consumption has been fixed in the 2017-05-10 version of Visual Studio 2017 (version 15.2, 26430.04) release.
Release notes are at Visual Studio 2017 version 15.9 Release Notes.
Specific notes about the fix are at
Node.js server-side JavaScript process consuming too much memory.
In my case I did not want to kill the Node.js process, and I did the following things to lower the CPU consumption of Node.Js processes that run under Visual Studio 2019:
I removed folder "Program Files (x86)/MicrosoftSDK/TypeScript
I run npm rebuild fsevents
I turned this off in Chrome browser: Settings-System-Continue running background apps ...
It now seems much better to me. But not 100% unfortunately.
To disable Language Services in Visual Studio Code, go to extensions, then filter on built-in extensions and disable the TypeScript/JavaScript language service.
I finally discovered this after Visual Studio Code's Node.js service crashed my server about a million times. It was annoying that this was so hard to find documentation about.
when i try to run a application developed in vc++ on windows7,i get popup window saying that"the program can not be started because MSVCR80D.dll is missing from your computer,try reinstalling the program to fix this issue."
I googled it,it says that this DDL may not be present in your system or it has been got corrupted,Now i searched this file, i get this file at 20 different folder in win7.
I am not getting which file has been corrupted or if it is missing then where it is mising?
can anybody tell in which folder ,this DDL is missing or might be corrupted?
Thanks in advance. .
You're trying to run a Debug version of your program on a machine which does not have VS installed. The MS*D.dll files are not redistributable - they are installed were VS is installed. If you want to run executables on other machines, compile them as Release. You might still need to deploy some files (depending on how you're linking to the CRT), but that won't be a problem.
Never ever distribute your DEBUG builds to customers. Always distribute Release build.
Yes, of course, in develoment environment having multiple machines, you may share Debug builds to other developers - provided others developers have debugging-tools (like VS) installed on their system along with Debug-binaries of shared DLLs (like MSVCRxx).
Are you using the same computer that compiled the program? If not, you need visual studio redistributable files to run it.
Search the internet for your version of visual studio or visual c++ redist, you'll find it.