This project is read-only.

Library debugging without requiring Attach to Process

Oct 21, 2014 at 7:20 PM
Edited Oct 21, 2014 at 7:53 PM
(I'll try to cut to the chase)
Node Tools for Visual Studio installed.
Edge installed
Express server invoking CLR library
I need to automate a way to debug the library directly with a stripped version of the Express server.

So, the way I approached this was to modify the MSBuild of the library's project file to add
<PropertyGroup>
<StartAction>Program</StartAction>
<StartProgram>$(SolutionDir)Edge.Express\node.exe</StartProgram>
<StartArguments>server</StartArguments>
</PropertyGroup>

The node executable is bundled with the development repository and server.js is co-located with it. If I remove the StartArguments, a node instance spins up and waits; however, the introduction of the server config file as a StartArgument results in

'The program '[9088] node.exe' has exited with code 8 (0x8)'

Note that I changed the StartArguments to a known to be invalid value ("foo") and the same error was generated, so it seems the error I'm getting is either a very generic one or the debugger cannot locate my server.js file.

[Edit]
So this is why I posted the question: having to think about communicating my approach in a way that others can consume has led me towards a solution. The StartArguments are obviously wrong. Changing it to be
<StartArguments>$(SolutionDir)Edge.Express\server</StartArguments> caused the debugger to at least attempt to load up symbols. The server instance that it spins up in the external console still crashes, and it seems to be reporting an error, but when it crashes, Visual Studio kills the process and I cannot get the error out of the spawned process in order to inspect.
Oct 21, 2014 at 7:55 PM
Holy Crap. PSR TO THE RESCUE!!! lol

The debugger is double referencing the path to my library, (C:\dev\project\library1\bin\library1\bin\library.dll) when it's supposed to be looking in (C:\dev\project\library1\bin\library.dll)

It took several attempts to get the timing of the mouse click right so that the error could be captured, but I can now see the problem clear as day and (thank god) it's actionable.
Oct 21, 2014 at 8:42 PM
Fixed. I can now Debug the NTVS project directly inside Visual Studio and I can also set my CLR libraries as the Start Up project and attach them to the debugger without manual developer intervention. A couple of copy BuildEvents for the library to allow each debug path (to keep from having to modify the server config's relative references) and everything works beautifully.