I guess prety much everyone who does a lot of debugging have a handy macro in Visual Studio (with shortcut to it on a toolbar) which when called automatically attaches to a particular process (identified by name).
it saves a lot of time rather than clicking "Debug" -> "Attach to the process ...", but it only works if one is running a single instance of the process one wants to attach to. If theres is more than one instance of particular process in memory - the first one (with a smaller PID?) is being choose by debugger.
Does anyone have a macro which shows a dialog (if more that 1 process with a specified name running) and lets developer to select to one he/she really wants to attach to.
I guess the selection could be made based on a windwow caption text (which would be suffice in most of cases) and when the particular instance is selected macro passes the PID of the process to the Debugger object?
If someone has that macro or knows how to write it - please share.
Thanks.
You can always attach to all instances...
Here is a macro I used when debugging asp.net applications - these typically have both a UI and a Webservice and I need to attach to both.
Sub AttachToAspNET()
Try
Dim process As EnvDTE.Process
Dim listProcess As New List(Of String)
listProcess.Add("aspnet_wp.exe")
listProcess.Add("w3wp.exe")
listProcess.Add("webdev.webserver.exe")
For Each process In DTE.Debugger.LocalProcesses
For Each procname As String In listProcess
If process.Name.ToLower.IndexOf(procname) <> -1 Then
process.Attach()
End If
Next
Next
ListDebuggedProcesses()
Catch ex As System.Exception
MsgBox(ex.Message)
End Try
End Sub
Related
I have an application that interacts with another one, suspending it while not used. If I end the debugging abruptly the suspended process will stay alive in the background and needs to be terminated.
I did some research and looks like none of the people found a solution that is applicable to Visual Studio 2015, in particular the macro solution will not work since looks like a dropped feature since VS2010...
My current solution is to run the proper taskkill command as a post-build action and within the startup code of the program.
I'm looking for a more elegant way of killing it, so a "post-debug" event like the one portrayed by the macro below would be perfect:
Private Sub DebuggerEvents_OnEnterBreakMode(
ByVal Reason As EnvDTE.dbgEventReason,
ByRef ExecutionAction As EnvDTE.dbgExecutionAction) Handles DebuggerEvents.OnEnterBreakMode
If (Reason = dbgEventReason.dbgEventReasonStopDebugging) Then
KillLeftoverProgram()
End If
End Sub
So is there any way to execute a cleanup shell command after using the stop button?
I have a ASP.NET 4.0 WEB API application running that modifies some database records.
My code iterates through Orders and Updates:
<[PUT]("ProcessOrders")>
Public Sub PutValue()
Dim Orders as List(of OrderInfo) = DAL.GetOrders()
For Each Order As OrderRequest In Orders
Dim Status As OrderProcessingStatus = Order.Process()
If (Status.isSuccessfullyProcessed) Then
DAL.UpdateOrderStatus(Order.OrderNumber, "SUCCESS")
Else
DAL.UpdateOrderStatus(Order.OrderNumber, "FAIL", Status.ErrorMessage)
End If
Next
End Sub
While debugging in VS2010, I have a break point on the first line where I get the orders.
In VS2010, I click on "Stop Debugging" - expecting that my code will immidietly stop and not execute.
To my surprise, even after I clicked Stop Debugging, the code keeps running and updates my database.
Please help.
Note: I start debugging, and then I use Fiddler to call this method
Thanks,
Simcha
Figured it out. Like Adrian McCarthy said:
If the process is started outside the debugger, and then you attach the debugger, the "Stop Debugging" command simply detaches the debugger from the process, and the process continues to run.
In the end, I used the "Terminate All" under the Debug menu. This actually stops all requests/processes.
If the process is started outside the debugger, and then you attach the debugger, the "Stop Debugging" command simply detaches the debugger from the process, and the process continues to run.
If you want to stop the process, then start it from the debugger. If that's inconvenient (e.g., if the process is started by another process on some event), then you'll have to kill the process in Task Manager and then stop the debugger.
Is there any plug-in for Visual Studio that can display the associated Application Pool name for those w3wp processes when debugging them with "Attach to Process..." ?
Usually I have to do following steps before debugging:
c:> \Windows\system32\inetsrv\appcmd list wps
then I get the process id for the Application Pool I want to debug, and then attach it in the Attach to Process window.
I feel it will be very pleasure if there's a plug in can do this automatically, but didn't find any such thing after Googled.
You can use a macro—see my answer to a related question. I am practically always attaching to one of a few specific Application Pools, so I’ve made buttons to attach to those specifically in one click. If you really want to choose from a dynamic list each time you’ll just have to build that dialog, but you can lift from my macro code to get the list.
I'm having an issue referencing public procedures of User Controls that I've created within a VB6 project.
A simple example (exe), I have a form with a button and a user control:
Option Explicit
Private Sub Command1_Click()
UserControl1.updateMessage ("TIME NOW: " & DateTime.Time)
End Sub
The User Control code is as follows:
Option Explicit
Public Sub updateMessage(ByVal newMessage As String)
Label1.Caption = newMessage
End Sub
This exe compiles and works fine, and when I'm typing updateMessage in the Form, it appears in the intellisense list with the appropriate requirements. The issue I have is when I'm wanting to "go to the definition" of updateMessage, instead of going to the appropriate section of the code within the User Control, the message always returns with:
"Cannot jump to 'updateMessage' because it is in the library 'Unknown1' which is not currently referenced."
where the numbered suffix of "Unkown1" changes from time to time.
It seems that if there were no reference to this procedure, then it would not appear in the intellisense and the project shouldn't compile. When running this with MZTools (though the error appears regardless of this plug-in being installed), I can go into the updateMessage procedure, and use it to find all procedures calling this function, so the link between the two should exist (although I'm not sure if MZTools just finds using a text-matching pattern).
If anyone out there could shed some light on this matter, it would be very much appreciated, and save this poor VB6 developer a lot of hassle!
I have SP6 installed (build 9782) of VB6 and am running XP SP3 on an HP dx2400.
Yes, this is extremely annoying and I'm convinced it's a bug in VB6. I say this because, if you locate the updateMessage method in the object browser and double-click on it, you are taken to the definition. So, the compiler actually does know where the definition is, it just refuses to take you there with Shift+F2.
My project has both client and server components in the same solution file. I usually have the debugger set to start them together when debugging, but it's often the case where I start the server up outside of the debugger so I can start and stop the client as needed when working on client-side only stuff. (this is much faster).
I'm trying to save myself the hassle of poking around in Solution Explorer to start individual projects and would rather just stick a button on the toolbar that calls a macro that starts the debugger for individual projects (while leaving "F5" type debugging alone to start up both processess).
I tried recording, but that didn't really result in anything useful.
So far all I've managed to do is to locate the project item in the solution explorer:
Dim projItem As UIHierarchyItem
projItem = DTE.ToolWindows.SolutionExplorer.GetItem("SolutionName\ProjectFolder\ProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect)
(This is based loosely on how the macro recorder tried to do it. I'm not sure if navigating the UI object model is the correct approach, or if I should be looking at going through the Solution/Project object model instead).
Ok. This appears to work from most UI (all?) contexts provided the solution is loaded:
Sub DebugTheServer()
DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
DTE.ActiveWindow.Object.GetItem("Solution\ServerFolder\ServerProject").Select(vsUISelectionType.vsUISelectionTypeSelect)
DTE.Windows.Item(Constants.vsWindowKindOutput).Activate()
DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
End Sub
From a C# add-in, the following worked for me:
Dte.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate();
Dte.ToolWindows.SolutionExplorer.GetItem("SolutionName\\SolutionFolderName\\ProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect);