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.
Related
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
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
I made an extension method for Action and I'd like to replace all occurrences of action() with action.SafeInvoke() in the code. But the problem is that action is just an example var name, and in reality they are all different. Searching by () will obviously produce terrible results. Searching by Action and looking up every individual var's references in code and finding direct invocation among that is kind of slow.
Is it possible to somehow find all occurrences of Action invocation by () operator when the variable names are unknown?
As I understand it, you have instances of type Action like:
Action foo = ...
Action bar = ...
And then you have in the code:
foo();
bar();
You want something that will change foo() to foo.SafeInvoke() and bar() to bar.SafeInvoke().
There's nothing in Visual Studio that will do this for you automatically, and writing something to do it would be non-trivial. You'd spend a whole lot more time on that extension than you would by making the changes manually.
You can use Visual Studio's "Find usages" functionality to find every place that Action is used. That will at least help you locate where you need to make the changes.
I'd be interested to know, what your SafeInvoke does. If all it does is a null check, you might want to consider if it's really necessary.
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).
I don't know that the following piece of code is really relevant, but for the sake of full disclosure here is the code I was trying to call from the Immediate Window:
abstract class Test
{
public int x;
public Test()
{
x = 5;
}
}
class TestImp : Test
{
public int GetX()
{
return this.x;
}
}
It was just a test to see whether the default base constructor gets called automatically or if I have to call it specifically because I couldn't remember.
Okay, on to the problem. I typed this into the Immediate Window to see the result:
new Mercury_Reports.TestImp().GetX();
And rather than evaluating the expression it just started my application. I closed the app and tried again two more times and got the same result. The next time, I went and put a breakpoint in my Program.cs file. Then instead of starting the app like it did the last three times and then hitting the breakpoint, it decided to actually just evaluate my expression.
I've seen some weird things in the Visual Studio IDE before, but I think this is one of the weirdest. Anyone have a clue as to what was going on there? :)
When evaluating an expression in the immediate window when you're not debugging the following process takes place
Loads your project / application binaries into the hosting process
Silently attaches the debugger to the hosting process
Evaluating the expression against that debugger session
Most of the time this is done in a way that makes it hard to detect that the application is actually being run. But occasionally a side effect of the application shows through and reveals what's really going on under the hood.
EDIT
In general it shouldn't be displaying the UI though. I can think of some obscure corner cases where this would happen though and not be a Visual Studio bug. The basically all come down to the same scenario though
The evaluated string causes an unintended side effect to happen at a time where it wouldn't happen during normal program flow.
This is actually more common than you'd expect in the immediate window because it's essentially executing your code out of order. Normally you'd never get to new Mercury_Reports before executing Program.Main but in the immediate window this is exactly what happens. This can have nasty effects like re-ordering static type constructors
Here are some unintended consequences which can surface via an immediate window expression
Cause types to be loaded and hence cause their static initializers to run
Change the order in which static initializers are run
The return type of the expression has a ToString method the debugger executes
The return type of the expression has a DebuggerDisplay value which the debugger executes
In the past I have seen the static constructor case cause UI to show. Essentially a static type constructor was evaluating MainForm.Instance (a lazy creation property). During normal program flow it was called from Program.Main was run and from then on was simply available. In the immediate window though Program.Main didn't run. But the expression being executed inadventently loaded that type and hence displayed the UI for what was a trivial property getter.
This is a pretty obscure corner case though. I'd say the most likely cause here is a bug in Visual Studio. Debugging is nasty business, especially when executing live code, and this is probably a symptom of that.