I'm doing some mobile development and sometimes things are easiest to debug by attaching to the server. For the sake of brevity, I like to write something like this:
Public Function GetData(parameters) As FuzzBomb
Using data As New PersistentDataAccessLayer()
Return data.MakeStateChangingCall(parameters)
End Using
End Function
However, if you have a string of function calls written this way (i.e. Return GetValueFromSomeFunction), it's really hard to inspect the value being returned while debugging.
Since there are side effects, I can't simply copy/paste the function call into the watch window. I could assign the results to a temporary variable... but that seems ugly to me:
Using data As New PersistentDataAccessLayer()
Dim result = data.MakeStateChangingCall(parameters)
Return result
End Using
Is there a better way?
This features is supported in Visual Studio 2013, .NET 4.5.1. Needed values will be appear in Autos window. You can find feature description in Somasegar's blog.
In old version of Visual Studio and .NET you can use Immediate Window: just write data.MakeStateChangingCall(parameters) from debugged function and Visual Studio will evaluate target value (result of function).
Related
Something that's bugging me for quite a while now...
I have to debug a lot of code that's not from me in Visual Studio and often I find functions like this:
Public Function DoSomething() As Object
...
Return Me.DoSomethingElse()
End Function
When debugging I like to move the mouse over a variable to see their content.
Is there any way to see the result of Me.DoSomethingElse() without leaving the function DoSomething and without stepping in Me.DoSomethingElse() (I might not have the source code of Me.DoSomethingElse() to step into). Something like moving the mouse over the Return (that's not working).
I don't like to change the code and put the result of Me.DoSomethingElse() in a temporary variable just to be able to inspect it, and I don't like to run Me.DoSomethingelse() in the Immediate Window either because that might change data I don't like to change twice.
I have a Visual Studio extension that hooks into debugging events. When the debugger stops at a line of code, my IDebugEventCallback2 callback gets called, and I can find out the filename and line number where the debugger has stopped via IDebugThread2::EnumFrameInfo.
I'd like to know the range of source code lines that the current function spans.
I'm hoping it's possible to derive the information I need from the debugger interfaces - the debugger must know the line range of functions. If that's not possible, I'm open to any other methods. In an ideal world the solution would work without the project system - many people, myself included, use Visual Studio as a stand-alone debugger without using the project system. (Also, I can't rely on Roslyn - it needs to work in existing versions of Visual Studio.)
Edit: Carlos's method of using FileCodeModel works well, as long as the file is part of a project. I'd still love to know whether there's a method that doesn't require the project system.
Given a FRAMEINFO retrieved with IEnumDebugFrameInfo2.Next, you can use the following code to get the file name, the first line of code of the current frame and the current line of code:
IDebugStackFrame2 stackFrame = frmInfo.m_pFrame;
if (stackFrame != null)
{
TEXT_POSITION[] begin = new TEXT_POSITION[1];
TEXT_POSITION[] end = new TEXT_POSITION[1];
IDebugDocumentContext2 debugDocumentContext2;
stackFrame.GetDocumentContext(out debugDocumentContext2);
if (debugDocumentContext2 != null)
{
string fileName;
debugDocumentContext2.GetName((uint)enum_GETNAME_TYPE.GN_FILENAME, out fileName);
debugDocumentContext2.GetSourceRange(begin, end);
}
}
FWIW, the IDebugDocumentContext2 interface has a Seek method that allows you to advance lines or statements of code in the stack frame. I guess you can advance until failure to get the end line of code of the stack frame.
To get info about code elements and start/end points using the project system (and without Roslyn) you have to use the automation model (EnvDTE.ProjectItem.FileCodeModel). Given a EnvDTE.ProjectItem and a line of code, you can use for example: HOWTO: Get the code element at the cursor from a Visual Studio .NET macro or add-in
When one steps into the debug function with multiple input parameters, it is a quite a time waster to enter and leave a copy constructor of each input parameter. Most often than not, these copy constructors are trivial (increase the reference counter), and what a developer really want is to "step right into function", and skip debugging through of input parameters creation,
be it a call to a copy ctor, or a call to a function which creates the instance of parameter object.
Is there a way in a Visual Studio to configure the debugging in a such way, as to avoid the debugging of the construction/copy construction
of the parameters and to go right to the function's body?
alt-shift-F11 in Visual Studio 10 or higher brings up a list of all the functions that will be called and you can select the function you would like to go directly to. I find this incredibly useful, but unsure if you are using VS10 or an earlier version.
While debugging an F# application, I would like to be able to invoke an F# method from the VS2010 immediate window but it doesn't seem to work. The problem appears to be that F# methods are actually FSharpFunc objects. I tried using the "Invoke" method but the interactive window doesn't recognize it.
The F# integration for Visual Studio doesn't support F# expressions in immediate window (or watches), so the only option is to write C# code corresponding to the compiled representation that F# uses. I tried doing that and I'm having the same issue as you described - the Invoke method appears to be there (in Reflector), but Visual Studio doesn't want to call it directly. I tried it using the following example:
let foo f =
let n = f 1 2 // Breakpoint here
n + 1
However, there are other ways to call the function. In this case, the actual code generated by the F# compiler is a call to InvokeFast method. If you type the following to the immediate window, it works:
Microsoft.FSharp.Core.FSharpFunc<int, int>.InvokeFast<int>(f, 1, 2) |
It also appears that you can call the usual Invoke method using dynamic from C# 4.0 (proving that the method is actually there!):
((dynamic)f).Invoke(1, 2)
This works only if you add reference to Microsoft.CSharp.dll (and use some type defined in the assembly somewhere in your code - e.g. as an annotation - so that it gets loaded).
I am looking for a method to monitor a running program that I have the source code. Basically, when the user runs it, I need to know what functions and parameter is called sequentially.
I can write a trace output code to all functions to achieve this. However, I am not allowed to modify the source code.
I found out that Tracepoint in Visual Studio 2005 allows me to do this - output log info without modifying the source. But I need to add them to all functions.
As I have thousands of files and functions, I need to find a way to programatically do this. I found out about DTE.Debugger.Breakpoints.Add that able to add a breakpoint. However, I couldnt find any way for tracepoint. Or where is the breakpoint info for a project stored? I couldnt find it in sln or vcproj. Or is there a way to convert breakpoint to tracepoint programatically? I see that I can change it manually by changing the "When Hit" property dialog.
Thanks!
You should cast your breakpoints to EnvDTE80.Breakpoint2. Then you'll be able to use
breakpoint.BreakWhenHit = false;
breakpoint.Macro = "YourMacro";
A .NET profiler will allow you to see which methods are executed and how long each takes without modifying the source code. It basically injects special code into the compiled assembly.
I think this is the solution... this macro adds a breakpoint the Main method of your program, and then turns all breakpoints into tracepoints.
Sub AddBreakpointToMain()
Dim bp As EnvDTE80.Breakpoint2
Dim bps As EnvDTE.Breakpoints
bps = DTE.Debugger.Breakpoints.Add("Main")
For Each bp In bps
bp.Tag = "SetByMacro"
bp.BreakWhenHit = False
bp.Message = "Hi, this is your tracepoint calling."
Next
End Sub
You could also look at Aspect Oriented coding. By my understanding this will change the compiled assembly controlled by attributes and is typically used to add tracing to all methods/properties.
How can I add a Trace() to every method call in C#?
First part of the solution:
DTE.ExecuteCommand("EditorContextMenus.CodeWindow.Breakpoint.InsertTracepoint")
It opens the TP window for the line where the cursor was. You will still have to hit Return to select OK, though. Enough for my needs--at least you don't have to right-click, etc.