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!
Related
I'm having a weird problem with Visual Studio 2010 Ultimate:
One of my Nunit(2.6.2) test cases is failing in the debug mode but passing in the run mode, as if we had completely different code paths for the two scenarios.
Is this a known bug? or is there some option in vs I'm missing?
Please enlighten me!
Thanks a lot.
EDIT - MORE INFORMATION
My application submits some requests to a dll written by a group of people within the organization. The dll does some computation and returns the results back to me.
In a test case exploring the dll's behavior (e.g. submit a request having certain parameter, check the dll's output), running the Nunit test works fine, but debugging the test case gives me an error - an exception was thrown from within that dll.
IMPORTANT: Running/debugging another test case gives me consistent results.
So, for the weird test case:
1, either the dll is good, and something under the debug mode breaks the dll
2, or, the dll has a bug, which is triggered by something under the debug mode.
To my knowledge, the ONLY difference between running and debugging a piece of code in visual studio is that, when debugging, a pdb file is loaded while when running it's not. Essentially, a symbol table is loaded to identify code execution.
Then the issue doesn't make sense in the first place - why would loading a symbol table affect the dll's behavior? (It's unfair to ask anyone to give an explanation without seeing any code; however, since it's corporate prop. code, I can't show it here. Please, if you've ever encountered such things in your career, do share with me what happened in your case - let's hope my problem has the same cause so that I can actually know what went wrong. Thanks)
Are you using code coverage?
If so, try disabling it and run. It will probably work.
For more details, check: http://social.msdn.microsoft.com/Forums/en-US/aba3d58f-f19f-4742-b960-8ac2be29bb88/unit-test-passes-when-in-debug-but-fails-when-run
You may have run into a situation where you're taking the same code path, but the results are subtly different in debug vs non-debug due to optimizations. There are a couple of distinct possibilities here:
Your code has a subtle bug, e.g. a race condition
Your test is being overly specific, e.g. for floating point comparisons where you should use a tolerance
It's a pain not being able to debug, but I suggest you add logging throughout the method and the test so you can see what's going on. (And hope that the logging itself doesn't change the test result, which is also possible...)
Thank you for your response.
I've identified the reason: it's due to a false parameter which drives the dll nuts. My bad.
It still doesn't answer the question why the behavior at debug time goes crazy, but good while running the test case.
However, I guess, since the parameter is wrong in the first place, I can't really blame the dll for going nuts. Anyway, when I passed in the correct param, all went good.
Thanks a lot guys.
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.
I noticed there's an attribute Microsoft.VisualStudio.TestTools.UnitTesting.WorkItemAttribute available in visual studio testing (I'm using VS 2010 Premium and work items with TFS 2010.)
Marking a test method with a work item number sounds handy, but does it actually do anything? I can't tell if there's any tool support for it at all. I set one up like this:
[WorkItem(25788)]
[TestMethod]
public void TestSomethingSpecificToABug()
{
...
But no magic - I thought maybe the context menu on the test in the Test Results window might offer to open the work item, or Team Explorer might have a feature to search for tests. The MSDN documentation is no help either. What is this attribute good for?
According to "Software Testing with Visual Studio® 2010" by Jeff Levinson (Addison-Wesley Professional, February 2011, ISBN-10: 0-321-73448-3):
This also means that one existing property should not be used anymore:
Associated Work Items. This value is not reported to the data
warehouse and therefore cannot be used for reporting. If you currently
use this property, consider associating your test with an actual Test
Case work item type.
So the answer is, don't use this with TFS 2010.
WorkItem Test Method attribute is not used for associating test methods to test cases. It is typically used to associate a test method with a bug.
A related C# example from Code Index - How to discover ignored tests:
When using MSTest to build your suite of unit tests, you can use the
attribute [Ignore] to tell the MSTest engine not to run a test instead
of commenting it. You may also use the attribute [WorkItem(id)] to
link the unit test to a bug database (such as TFS) item, so that you
can trace why a particular test has been marked as ignored:
[Ignore]
[WorkItem(12345)] // bug 12345 describes why this test was ignored
[TestMethod]
public void IgnoredButWithWorkItemTest()
{
//The actual code is not important;
}
It's to link the unit test back to a work item in TFS. I'd provide a link to more info but it seems it really is poorly documented.
I haven't used it myself but believe it can be used to generate reports on the status of work items.
This isn´t needed anymore: in VS 2013 via CodeLens
Find linked work items (Alt + 7)
Find linked code reviews (Alt + 8)
Find linked bugs (Alt + 9)
To review a test's definition, double-click the test.
Oh! for those that cherish Lync:
Contact the owner of an item (Shift + F10)
I really do remember, that I used this Attribute before and the test results have been attached to the respective WorkItem.
However, with Visual Studio 2012, it does not work anymore, or I forgot which mechanism was actually responsible for the magic. Could it be that this only works through the build server?
Pulling attributes from the test binary is really useful when you have a home grown test harness built for running Selenium UI unit tests.
After a test failure, I can pull the WorkItemAttribute value using System.Reflection.MemberInfo.CustomAttributes and then look up the ID with the TFS API. If the work item is a bug and it's still active, I can auto-resolve the failure to that bug. In this manner, I can run the failing test every day and automatically resolve the failure to reduce randomization.
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.