I'm trying to writing a visual studio plugin that launches the application to be debugged with out the debugger attached, and after some delay attach the debugger automatically to the process.
The reason I wish to do this is that starting my program with the debugger in a normal way takes a very long time as it seems to be taking ages when dealing with dll's even though I have disabled loading of dll symbols.
I have found plugin code that catch the debug event:
m_debuggerEvents.OnEnterRunMode += DebuggerOnEnterRunMode;
but have not found any way to launch my application as if I had hit the "start without debugging"
string VSStd97CmdID = "{5EFC7975-14BC-11CF-9B2B-00AA00573819}";
m_dte.Commands.Raise(VSStd97CmdID, (int)VSConstants.VSStd97CmdID.StartNoDebug, null, null);
There is also the following
DTE.ExecuteCommand("Debug.StartWithoutDebugging")
Related
I have an application that is always running on IIS, (the program is always deployed to IIS, and to update it you will need to rebuild the solution).
But I want to add a breakpoint on startup.cs for debugging purposes.
But since the app is already running I cannot hit the break point.
And if I want to rebuild the program then debugging mode will stop.
Are there any workarounds?
Thanks
MS Docs: Debugger.Launch Method
Launches and attaches a debugger to the process.
Debugger.Launch();
As mentioned by #Ibrennan208, Debugger.Break() might be a workaround if Launch does not work:
To build off of #MarkusMeyer if the Launch doesn't work, Debugger.Break() could also be a workaround, it will prompt you to select a debugger if you don't already have one selected. That being said, definitely try Launch before Break.
If no debugger is attached, users are asked if they want to attach a debugger. If users say yes, the debugger is started. If a debugger is attached, the debugger is signaled with a user breakpoint event, and the debugger suspends execution of the process just as if a debugger breakpoint had been hit.
Currently, when calling Debugger.Launch(); from a running application, VisualStudio breaks execution at the line where the debugger is launched and then I have to manually continue code execution.
Is there a way to stop it from doing that and to just attach the debugger without breaking at the line where it's launched?
If you run your app in Visual Studio using F5 (Debug|Start Debugging) then the debugger will start attached, no need for Debugger.Launch().
If your app is running externally then you can attach the VS debugger whenever you want to by using Debug|Attach to Process... and (based on a very quick test I've just done) this does not break into the process.
If you want to programatically attach the debugger from within a running process then this question and it's answers might help Attach debugger in C# to another process. Note in particular Dave Hillier's self-answer where he mentions it might be possible to use Process.Start to run vsjitdebugger.exe -p ProcessId.
I'm developing a Powershell module in C#, in Visual Studio 2017.
I am a bit surprised that the developing-experience is so bad in terms of running and debugging so I'm trying my luck here.
The way it works for me now is as follows:
Implement the module
Compile
Start a new Powershell window
Navigate to the bin/debug folder
import the compiled DLL (import-module)
Run the commands
Close the Powershell window (as otherwise I cannot rebuild the project as the DLL file is locked)
Fix bugs, and go back to step #2
In case I need to debug the code, I use VS2017 attach to process and debug the code (after step #5).
That is not ideal in terms of DX and I would like to have something better, as close as to this:
Implement the module
Compile
Press F5 (start)
Powershell window opens up with the module loaded
Run the commands
Breakpoints hit pause the program like we used to
How do I achieve that?
I managed to get this work with help of above comment from #Glenn:
Start your debugging with external program
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
and the parameter line
-NoExit -command "Import-Module '<path to your module>'; "
With this you can now start with F5 -> get a powershell window with your already loaded module and the Debugger is attached to this process.
But you have to be careful if your binary module is written to target .NET Standard. In this case it seems that the debugger (VS2017 15.8.9) is not able to detect which run-time modules to load. So no breakpoints hit at all in this scenario! My quick workaround here was to add another project with Console App targeting .NET framework 4.xy and use this other project as start project with above settings. Now my workflow exactly mirrors your second sequence (1-6). Unloading the dll is no issue because stop debugging does end the process.
As I understand it now, the only way to use the remote debugger is to start the target application, and then attach to it through Visual Studio. Is there a way to capture all of the breakpoints from the very beginning of the program?
There is code within my program that I need to debug, and I can never get the debugger attached fast enough to capture that executing code.
If you can change the code, try injecting this line of code in the starting point of your app:
System.Diagnostics.Debugger.Launch();
When this line is hit it will prompt you to attach a debugger, effectively waiting for you to respond. Since you are using a remote debugger you should be able to attach at that point and then just cancel the dialog. Hope this helps.
The solution
System.Diagnostics.Debugger.Launch
didn't work for me either. However, I managed to solve my problem writing in my application start up the following:
while (!System.Diagnostics.Debugger.IsAttached)
System.Threading.Thread.Sleep(100);
That way the application will be waiting until a debugger gets attached.
On the target machine set up the Visual Studio Remote Debugger that matches the year of Visual Studio on your local machine.
Note the line that gives you the server name.
On your local machine in visual studio, open the properties of your startup project and then open the debug section.
Check the box for "use remote machine" and then enter into the text field the server name you got from the Visual Studio Remote Debugger.
Under "Start Action", select "Start External Program". Then place into the field the path to the .exe you wish to start on your target machine.
Now when you press the start button from you local machine it will start the program on the target machine with the debugger attached.
With Visual Studio Pro 2010 building a .NET 4 application, this doesn't work for me.
Apparently this is a known bug:
https://connect.microsoft.com/VisualStudio/feedback/details/611486/debugger-launch-is-now-crashing-my-net-application-after-upgrading-to-net-4-0
A (somewhat hacky) workaround for the moment which is working for me is just to have the app throw up a MessageBox() right at the start of main window initialisation:
public partial class MainWindow : Form
{
public MainWindow()
{
// To allow you time to attach a remote debugger ...
MessageBox.Show("Please attach debugger");
InitializeComponent();
...
Now you can attach the VS remote debugger at your leisure, and then hit OK on the message box.
Ugly but functional.
The correct solution for me was a combination of the answers.
The while loop will check if the debugger is attached from Visual Studio and exit the loop when it is attached.
System.Diagnostics.Debugger.Launch();
while (!System.Diagnostics.Debugger.IsAttached)
{
System.Threading.Thread.Sleep(100);
}
When running a process under the debugger, I would like to start a child process in the same debugger.
Currently, I use
Process.Start("sample.exe");
I want it to be something like this:
if (Debugger.IsAttached)
// start "sample.exe" in the same debugging session
else
Process.Start("sample.exe");
I could pass a flag to the child process that instructs it to call Debugger.Launch(), but that won't catch start up errors, and it results in a debugging session where some features are not enabled (such as edit and continue, etc). It's preferable to have the debugger launch the process directly.
You should attach debugger to process you are starting. This could be done:
Manually from Visual Studio after starting "sample.exe" select it menu Debug > Attach to process..
Programmatically attach debugger inside "sample.exe"
Attaching to a Process using VS.NET Automation Model
UPDATE: You can setup windows environment to attach debugger every time "sample.exe" starts: Launch the Debugger Automatically (you will need to call Debugger.Break anyway)
Some external tool maybe
Here is code for "sample.exe" to attach debugger:
if (!Debugger.IsAttached)
Debugger.Launch();
Debugger.Break();
You should pass some parameter to "sample.exe" to verify if you need to attach debugger.
Process.Start("sample.exe", "Debug=true");
you can change the properties of your solution to start multiple apps.
an explanation is here Run Multiple projects
The MSDN article is here MSDN Article on running multiple projects
Assuming that sample.exe would be the host for code you want to debug, you can use project properties -> debug settings - choose action as an external program and provide path to sample.exe. The VS will start this executable and attach the debugger to it.
Visual Studio Debugger Team created an extension that does that automagically:
https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool