ASP.NET 5, DNX & Kestrel: Not hitting breakpoints

Question

Breakpoints are not being hit when debugging our DNX projects referenced in a ASP.NET 5 API project hosted with Kestrel (all in the same solution and in the src folder). Debugging with IIS Express works fine.

What troubleshooting steps can be taken to solve this problem?

No binaries or PDBs are created with DNX projects when debugging, so I am very unsure as to where to start.

project.json commands:

"commands": {
  "web": "Microsoft.AspNet.Server.Kestrel"
},

Project properties:

Note: Using the RC1 1.0.0-rc1-final libraries in all projects.

EDIT:

• Breakpoints in the Startup.cs project are hit just fine, but not in other projects.
• I have double checked and reinstalled the 1.0.0-rc1-update1 DNX runtime. I have uninstalled all other runtimes.
• I have confirmed that PATH reflects the DNX runtime correctly.
• I have deleted all project.lock.json files and DNU restored.
• The actual breakpoint pin is red and doesn't indicate that there should be any problem.

• global.json is using the correct runtime:

  {
    "projects": [ "src", "test", "." ],
    "sdk": {
        "version": "1.0.0-rc1-update1",
        "runtime": "clr",
        "architecture": "x86"
    }
  }
  

EDIT 2:

In the Modules window, I can see that the projects' symbols aren't loading:

How can I fix this?

EDIT 3:

I found that this problem only occurs when running multiple startup projects at the same time. When running a single project, debugging works just fine in all projects within the solution.

I have no idea how to fix this and why it is happening.

Answer 1

I have exactly same issue spend whole day and still no avail. I re-created project however it is strange enough that debug hit controller class for MVC Core in first debug after project created but not after that only main class i.e. startup.cs is hit breaking point everytime

Answer 2

I filed this issue on the aspnet/Tooling GitHub repository. Consensus is that this is a bug and will only be fixed with the Visual Studio 2015 Update 2 release.

An interim solution is to use a separate instance of VS for each process.

See issue here.