I am working on a fresh install of Windows 10 Pro (10.0.18362) and trying to get Visual Studio 2019 setup and configured for .NET Core 3.1 Web Development but am running into several issues.
I created a default React.js ASP.NET Core Web Application and ran the project. Things seemed to be working alright, except that after updating JavaScript code the browser updates after a fairly long pause; things seem to be lagging.
After closing Visual Studio 2019 from the default Web App (no updates) there are several processes that seem to hang, and have to be shut down manually:
I have tried installing Visual Studio 2019 with the Node.js provided by the Visual Studio Installer, in addition to installing Node.js V12.4 and V13.6 manually with the same results.
Another problem: If I update the project from JavaScript to TypeScript using npx create-react-app client-app --typescript, Hot Updates stop working entirely. But after updating the JavaScript code and refreshing the browser things seem to update, so it does seem to be recompiling. I have tried debugging in Firefox and Chrome, both with the same results.
I am very hesitant to continue working with this install as I have had several issues when these processes. If these hang unexpectedly and are not shut down they will continue to use the old versions of the code and nothing that is done will update until the processes are shut down, causing complete insanity.
Could there a specific install procedure I need to perform as a workaround? Or am I possibly missing NuGet packages or Add-Ons? Since this is a fresh install of the operating system, are there Windows Features that I need to install? Or other configuration/permission changes that could be causing this?
Prior to this install, only projects created in Visual Studio 2017 seemed to work as expected. But I need to develop this site in .NET Core 3.0 and it looks like only Visual Studio 2019 is supported for that.
Update
After some messing around, it looks like Node is causing the problems. If I manually shut down the Node processes, then Visual Studio will finally shut down—but it leaves other processes like the VSCompiler and Consoles running. This happens even if I run Visual Studio as an administrator.
Should I install node before Visual Studio, or visa versa? Is there possibly some setup that I need to perform with Visual Studio or Node to get things working correctly?
Update 2
After not finding any fix I tried a complete reinstall of Windows, including a disk format, and then only installed Visual Studio and Node.js.
One interesting thing I found when doing this: I originally only installed Visual Studio and selected both the "Web Development" and "NodeJS Development". But when I tried to run a new .NET Core Web Application without any changes, I received an error saying that Node.js was not installed—even though I was able to find a node.exe in the MsBuilds folder under Visual Studio.
I completely uninstalled Visual Studio and all other components, installed Node.js, and then Visual Studio, but the problem still persists. Any time I try to run any kind of JavaScript using the SPA Templates, the Node.js processes don't shut down. If I kill the Node.js process then Visual Studio will finally shutdown, but it leaves the Console Window Host and VBCSCompiler running which have to be shut down manually.
I also tried creating a new .NET Core Web Application, except this time selecting the Angular Template and it works better: The Hot Reload works and it seems to run much faster. But the processes still don't shut down. The only difference is killing the Node.js processes doesn't let Visual Studio shutdown.
Update 3
Also not sure if this helps, but I tried setting the node.exe properties to "Run this program as an Administrator" to see if it happen to be a permission issue. This yielded the same results. I noticed that two windows will pop up, however: First a blank one, then the actual Angular server window.
I'm not sure if it's related, but when I tried to run the Angular Application again it looks like Angular is pointing at another (random) port than is set in the debug settings in the project.
One thing I did notice is that the usual Server Messages are not showing in the Output Window. It used to display the node.js messages such as "the server is running" and other compiler messages, but now it only displays the .NET output.
Update 4
Getting closer, I uninstalled Visual Studio and Node.js, then made sure to clean out any left over Visual Studio and node_modules folders from my AppData and User/Local directories, and then did a disk cleanup. Finally, I reinstalled Visual Studio—making sure to run the installer as Admin—and reinstalled Node.js.
I ran Visual Studio as an admin and created a new Angular App. Now, the Angular app works as expected, HMR works and things seem to run smoothly except that the processes still hang. The major difference is that killing the Microsoft Visual Studio 2019 process kills everything, whereas before it was leaving the VBSCCompiler, Node.js and consoles running.
When creating a React App things load fine. But, again, the HMR doesn't work and also leaves processes running. shutting down the main Visual Studio process seems to clean these up now too.
I'm afraid I don't have a fix but if anyone wants a quick way to kill all the errant node processes and speed things back up they can run:
taskkill /IM "node.exe" /F
I haven't had any issues executing this while VS is running.
In Visual Studio 2019, go to Tools, Options, Debugging, General and towards the bottom there is a checkbox for Automatically close the console when debugging stops. It is unchecked by default on new versions of VS and if you look at your ASP.NET Core project properties you will see that it is a console project. So without the checkbox checked, the console does not automatically close.
The problem is that it is a hidden console so you can't see it to shut it down manually. If you check the box for closing the console automatically, then the consoles and node.js will stop running whenever you stop the debugger. Also in Options, there is a Node.Js Tools area that you may want to look at as well. It has a checkbox for Wait for input when process exits abnormally. If the console is hidden, there is no way for you to do input so that could hold the process open as well.
Another option, if you don't want to change any of the debugging options, is to go to your project properties > Debug and change the Launch settings for the IIS Express profile to Project instead of IIS Express. This will actually make the console / command prompt visible and when you are done debugging you can Ctrl-C to stop the debugger or when you hit stop the console will give you the message to Press any key to close this window . . .
I had the same issue with React SPA, this worked for me:
Tools -> Options -> Debugging -> General -> Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE) (Visual Studio 2017 and 2019) <- unchecked
also the dropdown next to the play button:
Script Debugging -> disabled
There are possibilities to run pre and post build tasks in Visual Studio. I would look for them in project settings.
I use VSCode. So, if you follow the explanation below you'll be able to tackle the problem.
Create a .bat file in your project root folder (for instance kill-node.bat) with the followwing content:
tasklist | find /i "node.exe" && taskkill /im node.exe /F || echo process "node.exe" not running.
Add a pre-build-task executing the .bat file
Add a post-build-task executing the .bat file
Done! Now every single time you start debugging/redebugging your app, the .bat file kills all node-zombie instances. And ditto for your stopping dubug moment.
The VSCode guide:
Perform step 1 of the algorithm above.
Open the file tasks.json in .vscode folder and prepend at top of its tasks the new one:
{
"label": "kill-node",
"command": "kill-node.bat"
},
Now alter the build task code (to activate our kill-node task at the pre-build time):
{
"label": "build",
"dependsOn": "kill-node", // <<< extra string to run kill-node task prior to build task
"command": "dotnet",
//... the rest of build task code
}
Open launch.json file and insert new string:
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (web)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"postDebugTask": "kill-node", // <<< extra string to run kill-node on debug end
//... the rest of launch.json file
}
}
That's it. Now you can no longer care of the node-zombie instances consuming your memory.
This should be fixed in ASP.NET Core 5.0, try upgrading if possible.
I'm trying to debug a deployed Azure Worker Role. I have the service published from visual studio and confirmed it is running on my Azure dashboard. In visual studio I right click the Instance of the role (only 1 is there) and select debug. After 5+ minutes I get the process dialog box and I select the WaWorkerHost.exe process. After that nothing is happening - I have a visual studio dialog that says "A remote operation is taking longer than expected". It has been 25 minutes so far.
1) I need to be able to debug my service and I'd like to do it vs the Azure published version. How can I debug this hanging operation?
2) 30+ minutes is not reasonable to wait for a debugger to attach. Is there any way to improve the process?
To be able to debug your Azure cloud service, you first need to make sure it is built with the Debug configuration and that the remote debugger feature is enabled, then you'll be able to attach to the role from Visual Studio as if you were running it locally.
You can follow these steps to enable the debugger and attach to the service: https://azure.microsoft.com/en-us/documentation/articles/vs-azure-tools-debug-cloud-services-virtual-machines/
How can I tell which of my services is the one that I am trying to debug?
Using the Visual Studio 2010 debugger I would just look for the w3wp (or whatever the heck it was) that was running under the app pool username that my service was running under.
But now in my attach to processs window I have 3 msvmnon.exe processes and I don't see any wcf services running? What am I missing?
What I wasn't doing was checking the show processes from all users.
Set your WCF services project as startup in VS 2010. Then run the project, you will get a window with all services defined on the left side. Click on the service you wish to execute and pass parameters if any
I have a Lightswitch 2012 application. It's been working fine for weeks. I made some changes and F5 stopped working. When I click on Start (toolbar) it gives this error message and does nothing.
"The Debugger cannot continue running the process. Unable to start debugging"
Note: It does compile file, it just doesn't run.
If I rollback to an earlier version then it works fine - i.e. it is solution specific.
Here is a video of the current version of my solution with the problem:
http://screencast.com/t/TD4RzLASO
and here is the previous version of the solution from earlier today (and no, I don't know what I changed). As you can see, at least it does something with F5 or Start:
http://screencast.com/t/wX5fRDPz
Rebooting doesn't help... ;)
Maybe you should select start up project which can be started.
Solution Explorer -> On your startable project right mouse click -> Set as Start up Project.
I had this situation when i unloaded my main lightswitch project and other project which is dll has been selected automatically and when i reloaded my main project "The Debugger cannot continue running the process. Unable to start debugging" exception was shown, because debuger was trying to load DLL.
Sometimes you need to start up a project which is compiled as a dll, for instance when testing WCF services.
To do so:
Projects -> 'Set Startup Projects...' -> Select 'Multiple Startup Projects' and set action to 'Start' for each one.
It's a pity you didn't recorded the whole screen, so I can't confirm, but I had the same error a few times...
When this happens, my "output panel" isn't visible and even I try to go on Menu -> View -> Output the panel don't appear.
I need to restart my Visual Studio 2013.
Then my output panel is visible again and everything works fine.
I discovered the cause was an extension which I installed on my Visual Studio.
I encountered this problem after removing some projects from the solution. I wasn't able to pinpoint the exact cause, but closing the solution, deleting the solution file, then opening the project and re-adding supporting projects solved the issue for me. Kind of a sledge hammer, but only takes a minute to do if you don't have a lot of projects.
Also, there are some people that uses a "One Click" Certification in your settings that you'll want to make sure its set up right, re-install or unchecked in-which this case was my problem. I finally got it working myself, but check that too just in case. Again this would be for most Visual Studio Versions only. Im 2013 Ult.
I have written an SharePoint EventReceiver (Windows SharePoint Services 3.0) and want to debug it with Visual Studio 2008 SP1, which runs on a different computer. I have tried the following steps:
Installing the event receiver (I know that this works because a log file proves that the code is executed).
Registering my event receiver class library in the GAC of the SharePoint server (built in Debug mode).
Starting Visual Studio Remote Debugging Monitor on SharePoint server.
Attaching to process w3wp.exe on SharePoint server from local machine.
Unfortunately Visual Studio tells me that the breakpoint I set will not be hit. I guess that when installing the assembly to the GAC the debug symbols (or whatever is needed for debugging) are lost.
What can I do to debug my event receiver? As far as I know the only way to extend SharePoint by custom assemblies is to deploy them to GAC - am I missing here something?
Best Regards
Oliver Hanappi
you could try manually copying your assembly's debug (.pdb) file to the c:\windows\assembly\MSIL\ASSEMBLYNAME\VERSION folder on the target machine and restart IIS.
I just ran into this issue this morning. I was getting the same error about breakpoints not being hit. In my case, it was because I attached to the wrong w3wp.exe process. If you have multiple w3wp.exe processes running on the server - make sure you're attaching to the correct process for debugging.
As an aside - you don't mention running iisreset anywhere in your steps. After you copy your custom event received assembly to the GAC - make sure you run an iisreset so that the web server is picking up your changes.
Hope that helps!!
This question is very old but I just want to share the following command that will assist in picking the right w3wp.exe process.
Assuming you have deployed and enabled your event receiver.
Execute this command on the commandline
%windir%\system32\inetsrv\appcmd.exe list wp
This will print the PID and an indication of which site it is for eg.
C:\Windows\system32>%windir%\system32\inetsrv\appcmd.exe list wp
WP "11632" (applicationPool:4a8cbf60637942ff9a2486d0e682ac54)
WP "16800" (applicationPool:SharePoint Central Administration v4)
WP "23648" (applicationPool:teams)
Now you can attach you Visual Studio debugger to the right process easily.
For example for the SP site teams I will attach to PID 23648