I am using a an assertion framework called Shouldly for C#.
The code looks like this:
[Fact]
public void SimpleTest()
{
false.ShouldBe(true);
}
This is the same as:
[Fact]
public void SimpleTest()
{
Assert.True(false);
}
However, when I debug the example that uses Shouldly, this happens:
But I want this to happen:
The issue
When I debug with Shouldly, Visual Studio steps into the source code of the Shouldly package. I don't want to see the internals, I just want to see what line of the test my code broke on. I can use the Stack Trace to find what line my code broke on but this slows down my flow a lot.
I remember when I first started debugging with Shouldly, VS asked me if it should download the source files (.pdb?) of Shouldly to debug with, I think I accidentally told it yes.
If I look at the Modules I have loaded in VS, it shows me this:
It thinks Shouldly is "User Code" which is probably why it debugs into this. How can I disable this?
I have this issue every time I change VS version. I've managed to fix it before but this time I can't figure it out.
You can disable symbol loading for a loaded module by:
opening the Module window
searching for the module you want to change
right clicking on it and disabling Always Load Automatically
Related
I know that I can attach a currently executing process during a debug session. However, I have not found yet how to debug a process that is launched from the Startup project. I have this process being launched with a few parameters, and I would like to step in its initialization, and verify that the arguments that are being passed are correct. In other words, I would like to step into the startup process, and then, after the new process is launched make that the debugger stops in its first breakpoint.
Can someone show me how to configure this scenario using Visual Studio 2010?
Thanks!
Your question isn't completely clear...but, one way is to insert;
System.Diagnostics.Debugger.Break();
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
System.Diagnostics.Debugger.Break();
}
}
}
A screen will pop-up and you can attach debugger:
Click Debug
Select instance of VS2010 you'd like to use (for example, use the one that has your solution open).
If this isn't what you're looking for, please provide additional details
We have a solution with multiple projects after running the code from VS the output normally seen from Debug.Writeline statements just cease to appear. I mention the multiple projects because the output from one of the projects continues to appear. However, the other project consistently stops showing the output from the statements.
It's starting to drive me crazy. I should mention this is also occurring for a second developer on the project. Anyone seen this before, or have any ideas?
After being tormented by this for years I finally found the cause and the solution in this Stack Overflow question: vs2010 Debug.WriteLine stops working
It seems that Visual Studio's handinlg of debug.writeline can't handle multiple processeses that each use multiple threads correctly. Eventually the 2 processes will deadlock the portion of visual studio that handles the output, causing it to stop working.
The solution is to wrap your calls to debug.writeline in a class that synchronizes across processes using a named mutex. This prevents multiple processes from writing to debug at the same time, nicely side stepping the whole deadlock problem.
The wrapper:
public class Debug
{
#if DEBUG
private static readonly Mutex DebugMutex =new Mutex(false,#"Global\DebugMutex");
#endif
[Conditional("DEBUG")]
public static void WriteLine(string message)
{
DebugMutex.WaitOne();
System.Diagnostics.Debug.WriteLine(message);
DebugMutex.ReleaseMutex();
}
[Conditional("DEBUG")]
public static void WriteLine(string message, string category)
{
DebugMutex.WaitOne();
System.Diagnostics.Debug.WriteLine(message,category);
DebugMutex.ReleaseMutex();
}
}
Or for those using VB.NET:
Imports System.Threading
Public Class Debug
#If DEBUG Then
Private Shared ReadOnly DebugMutex As New Mutex(False, "Global\DebugMutex")
#End If
<Conditional("DEBUG")> _
Public Shared Sub WriteLine(message As String)
DebugMutex.WaitOne()
System.Diagnostics.Debug.WriteLine(message)
DebugMutex.ReleaseMutex()
End Sub
<Conditional("DEBUG")> _
Public Shared Sub WriteLine(message As String, category As String)
DebugMutex.WaitOne()
System.Diagnostics.Debug.WriteLine(message, category)
DebugMutex.ReleaseMutex()
End Sub
End Class
Follow these steps, it works for me
Right click on your project
Select Properties
Select tab Build
Make sure Define DEBUG constant is checked
Hope that helps
I had the same problem with Visual Studio 2010. None of the above solutions worked in my case, but I solved it like this:
Right-click on your project.
Select Properties.
Click the Compile tab.
Scroll down to "Advanced Compile Options".
Change the value for "Generate debug info" from "pdb-only" to
"Full".
No idea what it's for exactly, but now my Debug.Print statements appear in the Immediate Window again I can finally get back to work.
you should try DebugView from Microsoft SystemInternals.
http://technet.microsoft.com/en-us/sysinternals/bb896647
Regards,
Allen
Try checking if Platform for the solution is set to Any CPU and not x86 (or x64). I used x86 to enable Edit and Continue and then lost Debug output. After going back to AnyCPU the Output is also back.
Got this in VS 2015. All of a sudden all Debug.WriteLine "stops working" (not showing in Output window). After going crazy about this for about an hour I found the problem:
1. Right click In output window (output from Debug)
2. Check that "Program output" is checked
I have a console app, and a class library.
I'm making changes to the class library (adding new methods, changing what methods do, etc) - Just regular stuff - nothing fancy.
In the console app - I'm calling methods from the class library - obviously to test the class library methods - again no rocket science here!
Both projects are targeting Framework 3.5 (This is because I have Sharepoint 2010 being referenced in class library)
Now:
When I debug the app using F5 - I've set a break point in the console app. When it steps through to the class library (using F11) I get a message saying source code has changed in a pretty lengthy dialog. If I click cancel - it then says No source code available.
I have found a work around to right click on project in solution explorer, then select debug -> create new instance.
But this is strange, never had this issue before, what can I do to get the debugger behaving normally. By normally I mean every time I hit F5 it should understand that the source code in the class library will almost surely have changed and I don't want any nags about this, or break point conditions never being met.
On a side note, never had this issue before, so an explanation as to why its happening would help a lot.
Thanks in advance
Update: the short version
Why do I have to manually tell the debugger to "create new instance" everytime I want to debug? If I don't hitting f5 debugs the source code of the last successful debug session.
Maybe your console application doesn't build second project? Try verifying that newest version of library is called.
In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.
since moving to Windows 7 (IIS 7.5), the debug assertions do not prompt a pop up dialog anymore.
I have tested this in a separate project, and noticed that they do work when using the integrated Visual Studio Developer server (Cassini) but they do not work when using IIS Web Server.
This is a big issue for us since we are counting on debug assertions to identify potential programming errors, so any help would be appreciated.
Thanks. Eyal.
That's because failed debug assertions are displayed in the Output window now instead, under the Debug section.
To view the Output window in Visual Studio 2008 go to the 'View' menu and click 'Output'.
I also find it inconvenient. Some more info...
You can work around by using
System.Diagnostics.Debugger.Launch();
You can make for example this function
[Conditional("DEBUG")]
public static void AssertEx(bool condition, string message)
{
if (condition) return;
System.Diagnostics.Debugger.Launch();
// Still write the message on output
Debug.Fail(message);
}
and get similar results.
That is the default behavior now and it cannot be changed.
What you can is generate a file with the assertions that failed in your app. That will still help you track your issues without halting the app when running inside the IIS.
Take a look at this good article about it.