I want to run my project in debug mode from the command line, not from Visual Studio (VS is open).
Is there any parameter to add to the command?
Actually, I want to initialize multiple instances of my project at the same time (from bat file) and debug them - instead of pressing multiple F5.
For debugging multiple instances of your application you can launch them separately from the command line (or press Ctrl+F5 in VS to launch the application without debugger attached) and then attach the VS debugger manually using the Debug -> Attach to Process... menu command.
If you want to automatically launch/attach a debugger you could add the following code to your Main method:
#if DEBUG
System.Diagnostics.Debugger.Launch();
#endif
This command should display the following dialog which allows you to choose the running instance for debugging:
(i.e. Figure 7 in this article: http://msdn.microsoft.com/en-us/magazine/cc163606.aspx)
You can start your executables from the command line by just typing their (path and) name.
You can later attach to those instances using Tools/Attach to Process...
Tools + Attach to Process allows debugging multiple processes. In the "Available Processes" list just click + Shift click to select all of them. Keeping track of which instance you're debugging when you set a breakpoint ought to be a bit tricky.
The .NET Framework SDK includes the command-line runtime debugger named CorDbg.exe
Related
I need to debug a process (starting from an external exe) that terminates immediately after start, so I don't have time to attach. How can I debug it?
UPD I don't have source code of that external exe; I can decompile it, but it's impossible to compile it back
You need to launch your process for debug in a suspended state. Visual Studio is capable of that, just invoke the debugger like this:
devenv /debugexe yourprog.exe <arguments>
The process will start suspended so you'll be able to iterate through first instructions before the crash.
See the detailed answer here.
You just need to open Visual Studio, go to File -> Open -> Project / Solution
and select the exe.
Press F5 and you will see the exception in the Output window. If you go to the Debug -> Exceptions window and select everything you will see the first chance exception before it shutdowns the application.
Note that you don't need the source code at all to do this.
Hope it helps.
You need to start it with the debugger. This will start the program with the debugger already attached.
If you cannot do that with Visual Studio, you can use the Windows Debugging Tools, part of the Windows Driver Kit. Note that the linked kit is for Windows 8.1, you may need to find older versions if you're not on Windows 8.
You can enable debug mode runtime by placing some piece of code.
write a method as below:
[Conditional("DEBUG_SERVICE")]
private static void DebugMode()
{
Debugger.Break();
}
and call this method where you want to start debugging, for example in the OnStart event.
you have to build your code with debug mode. dont forget to remove this piece of code after debugging and want to release.
When running a console application in Visual Studio via "Start without Debugging" (Ctrl+F5), the console remains open at the end of the run asking to
Press any key to continue . . .
thus requiring to activate the window and hit a key. Sometimes this is not appropriate.
Why this matters:
At the very moment I write json serialisation code, my workflow goes like this:
adapt c# code
run a console app that writes file out.json
view out.json in the browser with a json viewer
do this again and again, no need to debug anything, just trimming serialisation and check output is good.
It is workflows like this, where the "press any ..." behavior is hindering as it requires the steps
activate the console window
press key
.
No answers:
Starting the application outside VS in a separate console is not an answer.
Saying, you dont need this.
I'm pretty sure that you cannot affect or change this behavior.
As you mention, it has nothing to do with your application itself, because it doesn't do it when you double-click on the EXE. You only see this effect when you run the app from within Visual Studio without the debugger attached.
Presumably, when you invoke Ctrl+F5, Visual Studio is running your app in a particular way that causes the console window to remain open. I can think of two ways it might be doing it:
%COMSPEC% /k "C:\Path\To\YourApplication.exe"
or
%COMSPEC% /c ""C:\Path\To\YourApplication.exe" & pause"
With either of these, the pausing behavior you're seeing is baked right into the command used to launch your app and is therefore external to your application. So unless you have access to the Visual Studio sources, you're not going to change it. Calling an exit function from your app won't have any effect because your app has already quit by the time that message appears.
Of course, I can't see why it really matters, aside from an issue of curiosity. This doesn't happen when you start the app with the debugger attached, which is what you'll be doing 99% of the time when you launch the app from the IDE. And since you don't ship Visual Studio along with your app, your users are going to be starting the app outside of VS.
In response to the updates made to your question, the best solution would be to change your app so that it is not a console application. This behavior doesn't affect standard Windows applications; when they get closed, they close for good.
If you do not require any output on the console window, then this is very simple to do: just change the "Application type" in your project's properties. A Windows Forms application will work just fine. If you do not display a window (aka form), one will not be automatically created. This is the difference between regular Windows applications and console applications, which always create a console window, whether you need one or not.
If you do need to display output on the console window, you have a couple of options:
Create and use a simple form with a ListBox or ListView control. Each line that you would normally output to the console, you add as a new item to the list control. This works well if you're not using any "advanced" features of the console.
P/Invoke and call the AllocConsole function to create a console that your Windows application can use. You do not need a form for this.
I found a solution that works if you are using python (I could not test anything else).
You need to go to
Tools -> Options -> Python Tools -> Debugging
Uncheck Wait for input when process exits normally.
I hope you can apply this somehow to your problem.
2020 UPDATE : Microsoft has listened.
It also closes the console in "Start Without Debugging" mode ;)
The setting is a little buried, but works :
Well, at least in Visual Studio 2010, typing
Console.ReadKey(true);
Removes the "Press any key to continue....."
According to the VS2019 documentation:
Automatically close the console when debugging stops: Tells Visual Studio to close the console at the end of a debugging session.
It works, but only if you make sure your project starts with the debugger on. This sounds trivial, but I was trying at first with a solution with two projects, one Console one to copy files to use in my app, the other to run the actual app. I set the Console one to Start without debugging because I don't need debugging on it, but that did not close it after it ran. Only when setting it to Start (with debugging) this option worked.
In vs2017 you have to uncheck the python environment setting under the vs-options:
in german: Auf Eingabe warten, wenn der Prozess normal beendet wird
I tried the following steps in order to debug a particular custom timer ( installed and activated):
Copied the both .dll and .pdb files in the GAC.
Restarted the timer services.
Attached both w3wp and OWSTimer.exe processes.
But the debugging is still not taking place. The debugger placed is empty circle which displays this message:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
The OWSTimer is shown in a diff username. Does It needs to be run from my account?
Why debugging is not working?
Debugging Timer Jobs can be hard... The steps you took sound about right, but you can also do some more:
Timer Jobs run in OWSTimer.exe - you only need to attach to that one
Restart the timer service. For good measure throw in a restart, deploy, restart, iisreset ;-)
Did you do a DEBUG Build or RELEASE build?
Make sure you actually RUN your timer job (as in trigger it)
If your breakpoints are still not hit, do something ugly: use Debugger.Launch() or Debugger.Break() in your code or an assertion which will always fails: System.Diagnostics.Trace.Assert(false);
And then there is MSDN for the rescue.
Try loading debug symbols manually and see what it says:
To display the Modules window in break mode or in run mod
On the Debug menu, choose Windows, and then click Modules.
By default, the Modules window sorts modules by load order. However,
you can choose to sort by any column.
In the Modules window, you can see which modules have debugging
symbols loaded. This information appears in the Symbol Status column.
If the status says Skipped loading Cannot find or open the PDB file,
or Loading disabled by include/exclude setting, you can direct the
debugger to download symbols from the Microsoft public symbol servers
or to load symbols from a symbol directory on your computer. For more
information, see How to: Use a Symbol Server and How to: Specify
Symbol Locations and Loading Behavior.
To load symbols manually
In the Modules window, right-click a module for which symbols have not
loaded.
Point to Load Symbols From and then click Microsoft Symbol Servers or
Symbol Path.
copied from MSDN
You can also try to delete Visual Studio cache just to be sure (from command prompt):
del /Q %LOCALAPPDATA%\Microsoft\WebsiteCache
del /Q %LOCALAPPDATA%\Temp\VWDWebCache
del /Q %LOCALAPPDATA%\Microsoft\Team Foundation\1.0\Cache
Just adding to moontear's post.
I had the same loading debug symbols issue until I added in this code to the first line of my Execute method.
public override void Execute(Guid contentDbId)
{
// If in debug mode, trigger a false assertion to give time
// to attach the debugger to the OWSTIMER.EXE process.
#if (DEBUG)
System.Diagnostics.Trace.Assert(false);
#endif
...
Check to make sure your regional settings are correct - append /_layouts/15/regionalsetng.aspx to the CA URL. If you have the wrong time zone, your job may be scheduled for a time in the past. This has hung me up more than once. If this is the case, set the correct time zone (using the url above), stop and start the timer service (either services tool or open command line - net stop sptimerv4 then net start sptimerv4). Then attach to OWSTIMER and debug.
On the Start menu, point to Administrative Tools, and then click Services.
In the Services window, make sure the SharePoint 2010 Timer service is started.
Open the Visual Studio 2010 project that contains your timer job.
Set a breakpoint in the Execute method of your job definition class.
On the Debug menu, click Attach to Process.
In the Attach to Process dialog box, c
If the Attach Security Warning dialog box is displayed, click Attach.
In the SharePoint Central Administration Web site, click Monitoring and then click Review job definitions.
Click the name of your job, and then click Run Now on the Edit Timer Job page.
Verify that the Visual Studio 2010 debugger stops execution on your breakpoint.lick OWSTIMER.EXE, and then click Attach.
Question as per the title really.
I'm looking for a way to step through running unit tests using MonoDevelop on OS X in the same way you can with Visual Studio (by attaching the debugger manually to the nunit process).
If this is possible on MonoDevelop (on OS X) then it's not obvious how. Would appreciate any pointers.
Build your code as normal, then copy the exes, dlls and mdb files to your other computer.
On your debugger host set the following environment variable and run monodevelop:
$ export MONODEVELOP_SDB_TEST=1
$ monodevelop
(you might need to edit the actual script that monodevelop is launched with and add the first line)
Fire up monodevelop, load your solution, set a break point and then click Run > Debug With > Custom Mono Soft Debugger.
Once the dialog appears, replace 127.0.0.1 with the IP of your debugger. Then click "Listen"
Then, on the other host run :
$ mono --debug \
--debugger-agent=transport=dt_socket,address=IP:PORT \
nunit.console.exe yourtest.dll
Replace IP and PORT with the values given on the debugger.
So you are wanting to run NUnit and then attach to the running process?
I think the only way to debug NUnit tests are from within a MonoDevelop NUnit project. From there you can hit the Debug menu item, and it will start NUnit for you and handle your breakpoints, etc.
Note that you will have difficulty getting it to work with MonoTouch, see here.
I am testing an F# project using NUnit. On the debug tab of project configuration I have set the debugger to use an external program which is nunit-console here and the working directory to the debug folder of my project. I prefer using nunit-console with the debugger since the GUI version doesn't hit the test file's breakpoints.
When I debug the test the console window appears and disappears and there is no chance to read the output. I have tried Console.Readline(), but it doesn't work because when I directly run the test from a terminal using nunit-console, it fails due to this command.
Is there a way to redirect the nunit-console output to the Visuals Studio's output window?
UPDATE: I could use Thread.Sleep() to delay the nunit-console.exe when I run the test from the console. But from Visual Studio it doesn't happen so I am pretty sure that nunit-console.exe fails to read the test file when the command is issued by Visual Studio. Still, it would be very nice to be able to read the console output, thus the redirection is still desirable.
Either use Tools->Options...->Debugging->General:"Redirect all Output Window text to Immediate Window" and then make sure that the "Immediate Window" is visible with Debug->Windows->Immediate.
Or use NUnit's "/wait" command line option.
Unless I am missing something, you should be able to hit all your breakpoints with the GUI as well, set the startup project to nunit.exe and pass the name of your test DLL as a command line parameter. You will hit the breakpoints in Visual Studio, and your print statments will be in the GUI's output tab.