My debugger in VS 2012 will not break at any breakpoints in only one specific method in a class. It also wont step into that method from any calling code.
Other methods in that class are stepping into just fine. Even if I make changes to those methods and recompile, I can still step through them. If I make changes to this one specific method, they are NOT realised. It seems to be using an old version of this method... which is extremely weird.
I have tried everything mentioned in this comprehensive thread.
My breakpoints are solid red - they do NOT have the "The breakpoint will not currently be hit. No Symbols have been loaded for this document" error.
Any help will be greatly appreciated
This is embarrassing.
The reason is that my method was yield returning an IEnumerable and I hadn't began iterating through the stream on the client side, so obviously any breakpoints in my method would not be hit yet.
Related
I'm trying to port my console app over to a Blazor app. Everything worked fine inside the console type project, but it's not inside the Blazor project so I'm trying to troubleshoot. The app calls some things from a separate "class library" type project within the same solution.
The troubleshooting process itself is having issues of its own though. After a little bit of confusion I realized that the breakpoints set inside the referenced class library type project's code are not being hit.
Checking to console, I see it gives the error:
L: Unable to insert breakpoint at FtxApi.FtxWebSocketApi/<Test>d__5:MoveNext ():15
Is there anything I need to do (project settings or something) for the debugger to hit these? Or is it not supported at the moment?
Right now I'm just using a lot of Console.Writeline sort of as a workaround/replacement. And I noticed that the Console.Writelines inside the referenced class library type project are being called.. but only up to a certain method call that comes from a third party package. Execution seems to return from that point (nothing is called after it). Not sure what's going wrong there - more troubleshooting is needed, which brings us back to the breakpoints not firing (ideally I'd be able to make use of them).
I understand Blazor is new (and I'm an absolute beginner at using it), so not everything needs or is going to be perfect. I'm asking about the breakpoints kind of out of curiosity (I'd like to get them working but no big deal otherwise).
What I'd really like some insight into is: What might be going on with the code seemingly stopping execution / returning at that one particular method call? The method I'm calling is WebSocket.Open(), from the package WebSocket4Net. As mentioned above, I've tested this before (in a Console app) and it worked fine, so I'm guessing it's somehow related to Blazor which I'm unfamiliar with. I'm unsure how to get any more info to help debug this problem. Any help appreciated.
Edit:
I managed to find a solution to my problem without the use of debugging tools like breakpoints and such (I just used Console.Writeline a lot). I guess Blazor does not support some websocket implementations or something, because I found this error: System.PlatformNotSupportedException: Operation is not supported on this platform. blazor.webassembly.js:1 at System.Net.Sockets.Socket coming from websocket.Open(). I managed to get it working by implementing System.Net.Websockets instead, similar to this. Though my troubleshooting is over (for now), I'm still wondering if it's somehow possible to use breakpoints inside other referenced projects.
There are 2 solutions:
Solution 1: Right-click at Solution, choose Properties, choose Common Properties, Choose Multiple startup project, choose Action Start for Foo.Client, Foo.Server, Foo.Shared . Something like this
See https://blog.magnetismsolutions.com/blog/paulnieuwelaar/2015/04/07/debug-multiple-projects-at-the-same-time-in-visual-studio
Solution 2: Compile SharedProject, attacht PDB for debugging.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019
I used to develop code injection programs with Visual Studio 2010 (maybe 5 years ago?).
Now I need it again and I developed it pretty much the same as before (with Visual Studio 2015).
However, I have confirmed that the codes I have not seen before are generated.
The first thing I found is the above problem.
It seems that the program's entry point, the address of the function, uses the table without pointing directly to the contents.
The problem is that I can not find the address and size of the injected code.
Is there a way to disable it?
The second problem is that weird functions are added.
My injection code is code that calls CreateProcess, ExitProcess.
However, each address is called immediately after each function is called.
This is the part of 0x013A14CE : CALL test.013A1DA0 above.
The contents of the function are as above.
This problem causes a crash after injecting the code.
I do not know what this is doing, but I think it's code for security.
I found several compile options, but I could not solve the problem.
I tried to compile with Visual Studio 2010, but the result was the same.
Inline assembly seems to be able to solve this problem, but it seems hard to solve it every time there is a fix.
please answer my question
I am having a very frustrating problem in Visual Studio. I am using Resharper, and writing tests in Nunit.
If I set a breakpoint, it does get hit, however Step In/Over and Continue do not work, and the test never finishes. Even if I set two break points, continuing won't hit the second. If I debug a test without a breakpoint, it finishes fine.
Also, often and intermittently, when I try to debug a test by setting a break point, I can't evaluate the contents of variables, but instead see this message:
Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.
I am using Visual Studio 2010.
Please let me know if you have any ideas of what to look at... I have scoured the web, but without any luck.
Happy to provide further information if needed.
EDIT - Example of method
Test:
[Test]
public void OneRowAddedToSourceData() {
//Factory just returns System.Data.DataTable with correct columns.
var sourceData = new DataTableContainerFactory().GetTargetTableContainer(DataTypeNames.EventSharedEnd);
//GetRow just returns a populated row.
var row = GetRow(sourceData, 123456, 123,60, 31);
sourceData.DataTable.Rows.Add(row);
Assert.AreEqual(1, sourceData.DataTable.Rows.Count);
}
When I set a break point on the Assert statement, and try to evaluate the data table I get this problem.
UPDATE 2!
So, I have narrowed this problem down to Resharper Debugging. I changed a test class to MSTest rather than NUnit, but still got both the above problems when debugging with Resharper. However, when I ran the tests with the built in VS MSTest test runner, ALL the problems had gone!
Now I much prefer using NUnit and Resharper, so I would be very happy if someone could point me at a setting that will allow Resharper to debug properly!
I have a possible solution, albeit with a caveat. Did some searching and ran across this blog item. It suggests turning off Enable property evaluation and other implicit function calls from Tools->Options->Debugging->General. I turned it off and I can now go into items that previously caused this problem.
The caveat is that all the properties you're used to seeing automatically evaluated are now not being shown. Instead it states Implicit function evaluation is turned off by user. All you need to do is hit the Refresh button on a property and you can see the value, but I haven't decided whether this is a trade-off I'm willing to make.
I've found de way to solve this problem!
Check the option DEBUG->OPTIONS AND SETTINGS->GENERAL->ENABLE PROPERTY EVALUATION AND OTHER IMPLICIT FUNCTION CALLS and uncheck the option Call string-conversion function on objects in variable windows
This worked to me!
I'm currently dealing with a part-time (and annoying) bug with some extension methods in VB .NET (VS 2010 and VS 2008).
I have some client projects that use some extension methods from a "Framework" Project I created for general purpose.
However, sometime, when a try to start the solution, I get a long list of error saying the extension method "is not a member of" target object.
When this happen, I can rebuild the solution without getting any error but if I start the project again, the same error will be raised again.
So far I have 2 workaround
A) Go on the extension method definition, delete the tag, compile (with error), put the tag back.
B) Close Visual Studio et re-open it.
Is there any betterway to handle this problem?
There is an active bug report for this problem at Connect. There's a dire need for a repro, a project with specific steps to let them reproduce the issue in-house. Perhaps you can help, it's what it will take to solve it or recommend a workaround.
EDIT: one late addition to this answer, since I've posted this there have been additional questions that note a problem with the IntelliSense parser behaving different from the compiler. There's an issue with the multi-targeting feature, particularly in VS2010, triggered by the Client Profile option for .NET 4. It is the default for a new project. What goes wrong is adding an assembly reference that requires the full profile, commonly because of a dependency on System.Web. You'll get a warning for that, but that's quickly blown away with a large number of errors. The fix is to change the project's Framework Target from client to full.
I've recently encountered this same issue. My project would Build just fine but if I tried to use the Rebuilt option I would get the error about my extension methods not being found on the objects they were extending.
I have managed to fix this today by including an Import at the top of the classes using the Extension method.
So at the top of the file I actually have
Imports project_name.extension_module
I have no idea why this is required but it fixes the problem in my case. I hope this helps somebody else that has wasted as much time with this as I have!
Liam
A less time consuming work around than the two you listed is to "Rebuild Solution" instead of the normal Build Solution. This has always worked for me whenever I run into this problem.
We have something very similar. Call extensions merhod that extends type A. type is actually an instance of type B that implements interface C. interface C has a method with the same name as extension method.
Interface C declares method Foo
Class B inherits from A implements C
Static Class
Static method Foo (this A)
If A is C
(A as C).Foo
When debugging on the line if A is C it actually calls Foo multiple times and you can step at assembly level and see it indicates it is doing the comparison. The way we demonstrate that the call is happen Foo executes a sql statement and we can see sql profiler executing the code in Foo.
Change A as C to reflection and bug goes away. Or use debugger hidden/step through and bug is masked. Also if you micro-step the sql profiler shows the query is getting called multiple times (before Foo is actually called) for each assembly statement.
I have some code which generates a large quantity of ArgumentExceptions on one particular line (which is in a different developer's code, so I can't just change it), which are then caught and handled appropriately.
I'm trying to debug ArgumentExceptions which are happening in a different section of code (and are then caught and handled, so I can't just look at unhandled exceptions).
Is there some way to ignore the ArgumentExceptions originating from that particular other line of code, while still breaking on ArgumentExceptions which are thrown elsewhere?
You might be able to do this, but it depends on how the code you want to debug is located relative to the other developer's code, and whether or not you can modify (but not commit your changes) to his code.
The first thing you'll want to do is, at least temporarily, go to menu Tools -> Options -> Debugging in Visual Studio, and tick the "Just My Code" box. I assume this is available even in Express editions, but it may not be, and if it's not available for you I'm afraid the rest of what I have to say probably won't help.
Anyway, once you have that ticked, you will no longer see break-on-throw notifications for code that isn't "yours." This means code that is from an assembly not in your .sln, or code marked with the [DebuggerNonUserCode] attribute from System.Diagnostics. What I usually do then is temporarily decorate the offending methods with [DebuggerNonUserCode] until I'm done debugging what I need to debug, and then revert those changes before checking in to souce control.
It's not as elegant as I'd like (I'd love a "never break on throws from this site again" checkbox in the exception assistant), but it's better than nothing.
I believe there may be other debugger settings that could interact with how "Just My Code" works, so if this doesn't work for you let me know and I'll try to get a more accurate picture of what my settings look like when I do this.
If you are talking about the "Break On Throw" exception feature then no there is not. It is strictly a type based feature only and does not have any way to control for what section of the code throws the exception.
Your best bet is to just place breakpoints on all of the lines which throw or temporarily suspend throwing an exception from the one place that you care about.
If you know how you are calling it, I would set the break point in your code and then step into (F11) from there. You could also smack the programmer until they fix their code, which would have the effect of making you feel better (unless you are a pacifist) and maybe they won't have so many ArgumentExceptions in their code (which would probably make you feel better even if you are a pacifist).
Sounds like using exceptions as flow control. If the one you're trying to debug occurs later in the program, you can try to attach the debugger later, or you can wait until after the program is running to turn on breaking when an ArgumentException is thrown.
Try to limit the scope as well - if the exception you're interested in derives from but is not exactly ArgumentException, break on that one instead.
Tell the other developer to fix his code.
Edit: In .NET 4, you can attach a handler to the AppDomain.FirstChanceException event, filter out non-ArgumentException excepitons and filter out the bad one based on the call stack.
The links in the comments are great.
i think Conditional Breakpoints are what you're looking for here. You can do this by right clicking your breakpoint and clicking the Condition... menu item.