Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Web Development
  3. Debugging two ASP.NET projects with Chrome - Failed to launch debug adapter

Debugging two ASP.NET projects with Chrome - Failed to launch debug adapter

Scheduled Pinned Locked Moved Web Development
helpcsharpvisual-studiodebuggingannouncement
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    glen205
    wrote on last edited by
    #1

    Hi there: I have to debug two branches of the same codebase side-by-side (a development branch vs a release branch), as we're seeing unexplained differences in behaviour between them. I've opened two copies of VS 2019 (latest patch v18.6.3 at 16th Dec 2020), and when launching them, one will succeed, and the other will throw up an error message:

    One or more errors occurred.
    Failed to launch the debug adapter. Additional information be be available in the output window.
    Cannot connect to runtime process, timeout after 10000 ms - (reason: Cannot connect to the target: connect ECONNREFUSED 127.0.0.1:4318).

    What I've tried: - Making sure that each web project is set to start on a unique port number, I've selected 53199 for one branch and 53200 for another. - Delete the applicationhost.config inside .vs, restart VS and let it recreate. What I've noticed: - The two Visual Studios try to launch as tabs in the SAME Chrome instance. I loaded a random different project from another codebase and that project launched its own new Chrome instance. - Inside each applicationhost.config, in the section, BOTH projects have:

    - Their site "id" is the same, but each config file does have the correct virtualdirectorypath for its project location. - this is new behaviour (maybe a new bug?) and I've been able to run this configuration plenty of times in the past. - the output window contains only this: Verbose logs are written to: C:\Users\Bar\AppData\Local\Temp\visualstudio-js-debugger.txt The program '' has exited with code -1 (0xffffffff). The program '[21072] iisexpress.exe' has exited with code 0 (0x0). - as each site starts up, the visual studio debugger log shows a --remote-debugging-port which is unique for each site, so no conflict there... Since we're using TFS version control, "two branches" in this context means two completely different folders on disk, each with a full copy of the project source inside. I cannot see why these projects interfere with each other. Each one launches into debug successfully on its own and then the other won't launch. Can I "fool" VS / IIS Express by manually changing the site "id" or "name" in applicationhost.config? Any help gratefully appreciated! -- edit: there are workarounds, e.g. using two different browsers, but still would like to clarify whether it's me or VS or IIS express causing this, and whether it can be fixed!

    F 1 Reply Last reply
    0
    • G glen205

      Hi there: I have to debug two branches of the same codebase side-by-side (a development branch vs a release branch), as we're seeing unexplained differences in behaviour between them. I've opened two copies of VS 2019 (latest patch v18.6.3 at 16th Dec 2020), and when launching them, one will succeed, and the other will throw up an error message:

      One or more errors occurred.
      Failed to launch the debug adapter. Additional information be be available in the output window.
      Cannot connect to runtime process, timeout after 10000 ms - (reason: Cannot connect to the target: connect ECONNREFUSED 127.0.0.1:4318).

      What I've tried: - Making sure that each web project is set to start on a unique port number, I've selected 53199 for one branch and 53200 for another. - Delete the applicationhost.config inside .vs, restart VS and let it recreate. What I've noticed: - The two Visual Studios try to launch as tabs in the SAME Chrome instance. I loaded a random different project from another codebase and that project launched its own new Chrome instance. - Inside each applicationhost.config, in the section, BOTH projects have:

      - Their site "id" is the same, but each config file does have the correct virtualdirectorypath for its project location. - this is new behaviour (maybe a new bug?) and I've been able to run this configuration plenty of times in the past. - the output window contains only this: Verbose logs are written to: C:\Users\Bar\AppData\Local\Temp\visualstudio-js-debugger.txt The program '' has exited with code -1 (0xffffffff). The program '[21072] iisexpress.exe' has exited with code 0 (0x0). - as each site starts up, the visual studio debugger log shows a --remote-debugging-port which is unique for each site, so no conflict there... Since we're using TFS version control, "two branches" in this context means two completely different folders on disk, each with a full copy of the project source inside. I cannot see why these projects interfere with each other. Each one launches into debug successfully on its own and then the other won't launch. Can I "fool" VS / IIS Express by manually changing the site "id" or "name" in applicationhost.config? Any help gratefully appreciated! -- edit: there are workarounds, e.g. using two different browsers, but still would like to clarify whether it's me or VS or IIS express causing this, and whether it can be fixed!

      F Offline
      F Offline
      F ES Sitecore
      wrote on last edited by
      #2

      You could always just set them up as their own sites in IIS and attach the debugger of each instance of VS to the relevant site. I'm pretty sure what you're trying should work anyway so don't know if there is something odd going on with your project structure or what the sites are doing. I'd try the IIS route though as I know that definitely works.

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups