18

Kinda new to Visual Studio Code and Angular applications with a C# Web API back-end. No problem hitting a breakpoint in C#, just not hitting it in Angular app in VS Code!

I can run both apps just fine the in the browser, from the terminal, with dotnet run and ng serve BUT when I hit the debug button to debug my app, Angular breakpoints go from red to hollow grey!

Disclaimer - I have to mention that I changed lots of the file names and renamed the .csproj file because I wanted the app to reflect my name and not the one the instructor used. Before I did this, I was able to set breakpoints and hit them in the Angular app.

Here is what I've tried.

  1. restarted VS Code
  2. ng start, ng serve
  3. generated a new launch.json file (auto-generated by VS Code) in the same folder level that contains my two project folders (Ng, .Net)
  4. removed my workspace file (can't seem to generate a new one, not sure if I need to)

In the file:

error.interceptor.ts

I'm trying to test this exception handling by saying:

throw new Exception("Some login error");

in my Login method.

I can set a breakpoint shown below but it becomes a grey circle and never gets hit when I click Debug.

enter image description here

Here is where I set the breakpoints

enter image description here

Here is what I see when running the debugger, the red circles become grey and hollow. I'd like to be able to step through this error interceptor when debugging, is this possible?

enter image description here

and then in my login method from my angular app, my breakpoints become grey

enter image description here

Here is my launch.json file

{
  // Use IntelliSense to find out which attributes exist for C# debugging
  // Use hover for the description of the existing attributes
  // For further information visit https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md
  "version": "0.2.0",
  "configurations": [

    {
      "name": ".NET Core Launch (web)",
      "type": "coreclr",
      "request": "launch",
      "preLaunchTask": "build",
      // If you have changed target frameworks, make sure to update the program path.
      "program": "${workspaceFolder}/Yogabandy.API/bin/Debug/netcoreapp2.2/Yogabandy.API.dll",
      "args": [],
      "cwd": "${workspaceFolder}/Yogabandy.API",
      "stopAtEntry": false,
      "launchBrowser": {
        "enabled": true
      },
      "env": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "sourceFileMap": {
        "/Views": "${workspaceFolder}/Views"
      }
    },
    {
      "name": ".NET Core Attach",
      "type": "coreclr",
      "request": "attach",
      "processId": "${command:pickProcess}"
    }
  ]
}

Also - I'm seeing a lot of these lines when I run the debug console. Don't know if this is normal?

Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/2.2.4/System.Threading.dll'. The module was built without symbols. Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/2.2.4/System.IO.FileSystem.Watcher.dll'. Skipped loading symbols. The module is optimized and the debugger option 'Just My Code' is enabled.

Masoud Darvishian
  • 3,080
  • 4
  • 27
  • 37
user1186050
  • 10,710
  • 18
  • 92
  • 235
  • 4
    Are you happy to debug in chrome? – Avin Kavish Jun 13 '19 at 06:24
  • seems like you are starting the dotnet debugger – Markus Dresch Jun 13 '19 at 06:25
  • Markus. I would say 'yes' I think? But can't I step through the typescript code from the Angular app in VS Code when debugging? Or is the whole debugger part just for dotnet stuff? Maybe I'm loosing my mind, but I thought that at some point in an earlier part of the tutorial the instructor stepped through and hit breakpoints in VS Code from the Angualar app – user1186050 Jun 13 '19 at 06:27
  • https://code.visualstudio.com/docs/nodejs/angular-tutorial#_debugging-angular – Avin Kavish Jun 13 '19 at 06:29
  • Avin. Yes, I've installed the debugger for Chrome extension – user1186050 Jun 13 '19 at 06:30
  • add the line `debugger;` where you want to break execution. – Avin Kavish Jun 13 '19 at 06:33
  • You'll find it's much easier and more powerful just to debug the Angular stuff in Chrome. The developer tools are built in - just hit F12 with the Chrome window active. Go to the sources tab and look for the source code files, then you can debug in the built-in debugger. – Chris Halcrow Jun 13 '19 at 06:36
  • I was hoping he would discover that himself when he added the `debugger;` line :) – Avin Kavish Jun 13 '19 at 06:37
  • Ok, so why did I have to add 'debugger;' to a line in the ng app!? Because now that I've done that, it breaks on a breakpoint! I even removed the 'debugger;' line and it still breaks on a breakpoint! Weird! But the breakpoint that gets hit is from a readonly file that has the same name as the real file with the breakpoints. Is this expected behavior? – user1186050 Jun 13 '19 at 06:40
  • dubugger is the old way to break execution in a web browser, now you can put a dot next to a line. Seems like everything is working as expected? – Avin Kavish Jun 13 '19 at 06:43
  • Hi Chris. Just curious, I opened up the Chrome debugger and looked for any file that resembles, say, "app.component.ts", but don't see anything. Where would this be in the source area in the debugger? – user1186050 Jun 13 '19 at 06:49

5 Answers5

14

Here's what was going on! It has to do with the path to the project in the .vscode file and the need to debug two separate project/s folders at one time!

${workspaceFolder}

I have two folders for the app

  1. Yogabandy-SPA (Angular app)
  2. Yogabandy.API (ASP.Net Core Web API)

I thought the best place for the .vscode file was at the root level, and unless someone has a better solution this seems to be the best place.

enter image description here

But the problem is the path of the workspace folder needed to be corrected.

Corrected paths

"webRoot": "${workspaceFolder}" // old
"webRoot": "${workspaceFolder}/Yogabandy-SPA" // new
"program": "${workspaceFolder}/bin/Debug/netcoreapp2.2/Yogabandy.API.dll" // old
"program": "${workspaceFolder}/Yogabandy.API/bin/Debug/netcoreapp2.2/Yogabandy.API.dll" // new

// removed from the 'server' command so two debuggers don't open, just one
"serverReadyAction": {
  "action": "openExternally",
  "pattern": "^\\s*Now listening on:\\s+(https?://\\S+)"
},

Added a compound so that I could debug both projects together.

"compounds": [{
  "name": "Server/Client",
  "configurations": ["server", "client"]
}]

I'm still having a minor issue starting the debugger. VS Code displays this below, but I am able to now debug both apps together and hit all breakpoints from both projects. enter image description here

If anyone has a better solution please let me know.

"compounds": [{
  "name": "Server/Client",
  "configurations": ["server", "client"]
}],
"configurations": [{
    "name": "server",
    "type": "coreclr",
    "request": "launch",
    "preLaunchTask": "build",
    "program": "${workspaceFolder}/Yogabandy.API/bin/Debug/netcoreapp2.2/Yogabandy.API.dll",
    "args": [],
    "cwd": "${workspaceFolder}/Yogabandy.API",
    "stopAtEntry": false,
    "env": {
      "ASPNETCORE_ENVIRONMENT": "Development"
    },
    "sourceFileMap": {
      "/Views": "${workspaceFolder}/Views"
    }
  },
  {
    "type": "chrome",
    "request": "launch",
    "name": "client",
    "url": "http://localhost:4200",
    "webRoot": "${workspaceFolder}/Yogabandy-SPA"
  }
user1186050
  • 10,710
  • 18
  • 92
  • 235
8

It seems you haven't configured chrome debugger extension in launch.json file. from vscode documentation:

We need to initially configure the debugger. To do so, go to the Debug view (ctrl+shift+D) and click on the gear button to create a launch.json debugger configuration file. Choose Chrome from the Select Environment drop-down list. This will create a launch.json file in a new .vscode folder in your project which includes a configuration to launch the website.

We need to make one change for our example: change the port of the url from 8080 to 4200. Your launch.json should look like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:4200",
            "webRoot": "${workspaceFolder}"
        }
    ]
}

Press F5 or the green arrow to launch the debugger and open a new browser instance. The source code where the breakpoint is set runs on startup before the debugger was attached so we won't hit the breakpoint until we refresh the web page. Refresh the page and you should hit your breakpoint.

Community
  • 1
  • 1
amirali
  • 1,490
  • 6
  • 26
  • 1
    Use 'chrome debugger' and put 'debugger' in the code (the function, where you want to debug) , this will hit the code without break point. method () { debugger ... } – RajuPedda Jun 15 '19 at 20:35
  • 1
    While that indeed works it's not the ideal solution, the breakpoints should work on their own without debugger statements. – jbaranski Aug 07 '19 at 14:25
2

Mine, even being in the same folder as the project, only worked by including '/ src' in $ {workspaceFolder}.

Folder Directory

Folder Directory

launch.json configuration

launch.json configuration

tiagorockman
  • 311
  • 2
  • 5
1

Anyone who is looking for a quick fix try this:

make sure your port number in the Launch.json settings is same as the one you get after "ng serve" command. usually it is "4200" and try to include both launch and attach settings in Launch.json.

once "ng serve" is completed and angular server started listening try to click "start debugging"

then the debugger will lauch a chrome instance on 4200 and after that you can see the break point will be bound.

Do not launch it manually by typing the link(http://localhost:4200/) in browser

0

Just in case this was not helpful, I had the same problem, just because of wron angular.json configuration

"development": {
          "buildOptimizer": false,
          "optimization": false,
          "vendorChunk": true,
          "extractLicenses": false,
          "sourceMap": true,
          "namedChunks": true
        }

without this configuration, it's handled like production and You are not able to stop at breakpoints.

Collin
  • 83
  • 9