I am trying to add assert statements to a project, but they keep being skipped. Is there an option I need to enable somewhere?
The assert statement is:
Debug.Assert(false, "Deserialization failed", "Deserialization failed");
And I am running in debug mode. I could be doing something silly; I am not sure.
Make sure the DEBUG conditional compilation symbol is defined. In VS2008 that's on the project's property page on the Build tab: "Define DEBUG constant". This should be the case by default for a debug build, but it's possible that it got switched off.
It may be set/unset in similar but different ways in other IDEs (possibly with an edit control instead of a checkbox).
It's also possible (but rather unlikely) that it is being disabled by a configuration file setting, either with an <assert assertuienabled="false" /> setting or because the DefaultTraceListener has been removed from the Listeners collection. See the documentation for the Debug.Assert() method for more details if you think this might be what's going on.
Related
I am using VS2010.I was changed my project and its dependent projects .Net Framework to 4.0 from 3.5.Now I could not attach the process,due to this I am not able to debug the code.
I have cleaned all the bin folders and rebuild the projects ,but still I am having following error.
Please help me to resolve this..
I'm not sure what the question is here. The error message clearly tells you that you need to
Turn off (disable) optimizations
Turn on (enable) debug info
Rebuild your project so those changes take effect.
Apparently you only did step #3.
Also see vs2010 debugging module was built without debugging information?, which may provide more information.
I also received this error, and did all the right things as described above - those have been my settings all along anyway. I even went so far as deleting the assembly from the long C:\Users... path in the error message - it still didn't cause that message to go away.
Then I tried putting a breakpoint in the source, which should not be allowed if the module really WAS built without debug information. And then ran the program and it stopped at the break point and I could do all the usual debugging.
So right now I'm just ignoring the message. I could do as suggested and disable the 'Warn if no user code on launch' option as suggested in the message, but I'm not doing that until I can spend some time working out why the message comes up at all.
Uncheck this option in Visual Studio 2012.This would solve this issue
I'm trying to debug my unit tests (xunit) under Visual Studio 2012 (via Test Explorer -> Debug Selected Test).
But I can't step into my code of target library. In Modules window I see, what my library symbols are loaded, and the symbol file is found. But in "User Code" column it marked as "N/A" (like all other libraries, include running test library).
Project in Debug configuration isn't optimized, just xml documentation file generation is defined.
How to make VS determine my libraries as "user code" in debug mode?
Solved! Problem was in code. I'm using method which return IEnumerable<> via yield return, and I just call this method (without any iterations on results). So because of yield returns specifics actually this method wasn't called.
So, be careful with yield returns! It may lead to "strange" behaviour like this one :)
I was having this same issue but noticed that my build was targeting "Release" instead of "Debug".
Interesting, since I click on "debug selected tests" I hope it will get debugged, not simply ran on selected build.
I'm having a strange issue with unit testing in Visual Studio 2010.
I have a test that passes when I use "Debug test" (without any breakpoints), but failes when I use "Run test".
This test uses external dll's, so I can't debug it properly.
Do you know of any reason why a situation like this is possible?
Why "Debug test" is different than "Run test", when all other parameters are the same?
Switch you solution to Release mode instead of Debug, run a full build, switch back to debug and retry and let me know the outcome, I think the tests will pass....
There can be several reasons, but to pin-point one, you'll have to give us some code to work with.
It could be code exclusion:
#ifdef _DEBUG
//do something
#endif
This will only be executed in debug mode.
It could be optimizations. Although they shouldn't normally affect the behavior, you shouldn't rely on destructors or copy constructors being called.
If you're doing any hacking inside the code, it might also only be valid for debug.
I'd suspect that you are accessing memory out of bounds. One major difference between debug and release is that debug adds kits if padding and special markers to memory allocations to catch certain kinds of errors. This means the memory layouts are often very different between debug and release builds. I would suspect that you are accessing memory out of bounds in a way that the debugger isn't catching, where you find an accidentally valid value in the debug version, but an invalid one in the release version.
We like the Warnings as Errors setting as we have a policy of not checking in code with warnings and this is the only effective way we have found to enforce it.
We also like to use the Obsolete attribute to flag methods that should not be used any more.
Problem is that adding a Obsolete attribute to a method or class immediately causes tons of projects to not build (not to mention problems if a .NET API call is deprecated).
Does anyone have a good solution to this?
We want a visible, hard-to-ignore indicator that you are using a deprecated API but that does not cause the build to fail. We want to see the warnings in the IDE and in CI builds.
A simple solution would be to have a build configuration (e.g. your debug build configuration) without warnings as errors. If, however, the point is to flag to your developers that something is wrong on build, that's no good as they'll forget to do a release build before they check in.
Alternately, rather than using "warnings as errors" you could set up your ruleset to throw errors itself rather than raise warnings. This will mean, of course, that non-CA warnings won't cause errors.
The best solution, I think, would be to handle it on the server side. Ideally you'd have some sort of gated checkin so that your code repository rejects commits that don't build using its build definition (with warnings-as-errors on, and your developers can leave warnings-as-errors off). I suspect that's a TFS-2k10-only feature though.
This other stack overflow post should help:
https://stackoverflow.com/a/468166/9195608
Basically it says:
You can add a WarningsNotAsErrors-tag in the project file.
<PropertyGroup>
...
...
<WarningsNotAsErrors>612,618</WarningsNotAsErrors>
</PropertyGroup>
Note: 612 and 618 are both warnings about Obsolete
The difference between 612 and 618 is the comment of the ObsoleteAttribute. An ObsoleteAttribute without comment generates the error 612, and one with a comment generates 618.
As explained here /sdl (Enable Additional Security Checks), if you switch off SDL the compiler will treat it as a warning.
I made a simple change of a property to an auto property and broke the build because the property was referenced in a conditional compilation section. I was building in debug and the reference was in a section of code that's only compiled in release configuration. Is there any way to catch these errors without manually switching the build configuration in Visual Studio and building in each mode?
I have a CI server so the error was caught right away but I hate breaking the build.
You need to build each configuration to see if something conditional breaks one of them. You can avoid the manual step using the 'batch build' option from the build menu though.
You have to build under each configuration.
Remember that if you were to use all the conditional compiled sections at the same time, its likely that it wouldn't build i.e. if is debug use a, if not use b.
You don't need to do it manually though - that said, double compilation time is an awful thing.