I have two projects in VS2015. The executable from start up project at some point needs to open the output executable from the second project. (by using Process.Start)
How can I debug the second executable as well as the main one? Can VS include the second executable in the output directory and setup debugging automatically?
Either attach the debugger manually after the second process started (using Debug -> Attach to process) or use the Microsoft Child Process Debugging Power Tool
Related
I have made a program on visual studio (2019) and want to run it without using the debugging mode without visual studio open.
Debug > Start without Debugging.
The shortcut is Ctrl-F5.
Edit: After building, you can simply launch the executable code in the build output folder. For example, for an executable C# .NET project, this will be something like /MyProject/bin/Debug/MyProject.exe
where MyProject is your project's name, and Debug will be the configuration name (e.g. Debug, Release, x86, etc).
I want to create a custom VS project that builds a DLL, but when hitting F5 will run a custom executable that I wrote (which gets the DLL path as parameter).
Is this possible? What API should I use?
Yes, it's easy.
In the project properties, in the Debug tab, select the Start Action 'Start external program'. This program must be your executable.
I have a Visual Studio solution with an executable and a hot-swappable dll (plugin). The executable runs a file system monitor in the directory where the dll is built and when a new version is generated, it reloads it and continues working with it. One of the crucial things here is that the executable state is preserved between reloads of the dll.
Now this works fine if I run the program without debugging (Ctrl-F5) and then just build when I have changes in the dll code. The dll is reloaded, the new functionality executed, and it's a charm. The problem is when I want to debug the dll.
Unfortunately Visual Studio doesn't allow me to build while debugging. So the only thing that does work is if I run without debugging and then periodically attach and detach the debugger from the process when I make changes and want to debug the dll. This is pretty cumbersome. Especially when I want to debug the plugin init function. In such case I have to add a break in the executable before calling it (say a message box: "Plugin loaded, but init not called. Attach to process now if you want to add breakpoints in init).
Is there a Visual Studio workflow where I can skip the constant manual reattaching to the process?
(Xcode with its explicit target selection, for example, does allow me the dream workflow, where everything just works and I can build the .dylib while debugging, without explicitly reattaching the debugger to the process. init breakpoints working and all)
I wonder if I can run multiple instances (right now two instances) of my application in debug mode by doing a simple click or set a key for that...
Not many people seem to know this, but this is perfectly possible, though I admit it's not very obvious.
Here's what you do:
suppose your current project is A, and it's output is c:\bin\my.exe
add an empty project to the solution for A, call it 'Dummy'
under Dummy's Project Properties->Debugging set the Command to point c:\bin\my.exe
under Solution Properties->Configuration Manager, uncheck all builds of the Dummy project so VS won't try to build it (building an empty project fails)
under Solution Properties->Startup Project, select Multiple Startup Projects and set the Action for both A and Dummy to Start
now hit F5 and your exe will be launched twice, each under a seperate debugging instance. (as you will be able to see in the Debug->View->Processes window)
You can use "Multiple Startup Projects" feature, but avoid creating dummy projects by hand: just add your debuggee executable into the solution directly:
Solution > Add existing project > Path to .exe
If you neeed several instances, Visual Studio won't allow you to add the same executable twice, but adding a symlink to it with another name works as expected.
MSDN: How to: Debug an Executable Not Part of a Visual Studio Solution
Is Visual Studio 2013 this is even easier!
Project-> Properties -> Debug -> check "Start external program" and click the ... button, navigate to your .exe of the other program.
Then Make sure in your Solution -> Properties -> MultipleStartup Projects that it's checked.
You can run two instances of your application from where it is built; example: d:\test\bin\debug\app.exe and attach both instances to the Visual Studio 2010 debugger.
I've been using CMake for quite some time to generate VS 2008 solutions to build a program, its installer, and its packager (as well as several test programs). In order to run, the program needs several dlls which the install project puts into a bin directory, along with the generated executable. Under VS 2008, if I want to debug the created program, I build the INSTALL project, and then click Debug->Start Debugging. The first time I do this after generating the solution, this presents me with a dialog from which I can browse to the bin folder and then the desired executable.
However, under Visual Studio 2010, after clicking Debug->Start Debugging, I do not get the dialog, but rather get the message that it can't find the ALL_BUILD program (which does not, and should not, exist). I can change the start up project to be the executable in question (or right click on it and choose debug), but then that loads the executable from the wrong path and is therefore unable to find the dlls. I know that I could either add the dlls to my system path or copy the dlls into the same directory where the executable is initially created, but these are less-than-ideal solutions (for testing and portability reasons), and these steps were not required in VS 2008.
This is the exact same CMakeLists.txt file for both cases, and the exact same source code. The only difference is that CMake is run with the "Visual Studio 9 2008" generator in the first case and the "Visual Studio 10" generator in the second case.
I can run the generated program from the bin directory using Windows Explorer, but I am not able to debug it (e.g., step through a problem area line-by-line).
You need to edit the debug properties of your start up project so the command line and working directory match your install location.