For some reason, conditional breakpoints suddenly became disabled in one of my project. I'm having a hard time to find any documentation on internet on the potential conditions that could disable these options. Anyone know why it became disabled, and how to fix it?
Here are some information:
It's a C# solution with about 50 C# projects, and a few shared projects and C++ projects (No project added/removed recently)
I use Resharper 8 on Visual Studio 2013 with Update 4
Closing/reopening Visual Studio didn't solve the problem
Related
I recently updated from Visual Studio 2017 Community Edition to Visual Studio 2019 Community Edition.
Now, if I build my solution with errors, they will show up in the build output, but not all of them will appear in the error list. It would appear only errors of open files will show up in the error list. This is incredibly annoying.
I am not alone in this issue. It has been reported many times on Microsoft's forums, but no one has a definitive solution.
I have tried a variety of solutions people suggested in those threads:
I have ensured the filters are legitimate: Entire Solution, Errors enabled, Build + Intellisense.
I have tried deleting the .vs folder and restarting Visual Studio.
I just updated to the very latest Visual Studio 2019 version. Supposedly there are many different versions of this error, happening in versions of Visual Studio all the way back to 2017. Some supposedly have been fixed...?
I have disabled parallel project loading.
I have experienced this before in other versions of Visual Studio with Razor pages. To my knowledge, that's to be expected in Razor though.
The only other factor that I severely doubt impacts anything is that it's a Visual Studio project generated by Unity editor. From what I've read, ASP.NET, Razor, Xamarin, and other frameworks have each had their own version of issue reported. Perhaps Unity is afflicted by it too, but I don't see how or why. I doubt Unity's auto-generated Visual Studio projects are that different from your standard library projects.
I have now installed Visual Studio 2019 on two separate machines, and it appears that "Full Solution Analysis" is disabled by default.
Simply check the checkbox in options and everything seems to work as it did previously:
For those using Visual Studio 2019 v16.9.1 make sure your Error List window looks something like this:
The important part for me was selecting Build + IntelliSense (previously it was set to Build Only which explains why the error list would only refresh on build).
In my case the solution was to switch off 'Tools->Options->Projects and Solutions->General->Show output window when build starts'. Even though the 'Output' window showed "0 succeeded, 1 failed" it would not switch back to the 'Error List' window even that the checkbox above 'Always show Error List if build finished with errors' should have moved it to 'Error List'. Clearly a bug in Visual Studio 2019 which was not present in Visual Studio 2017 (I just finished updating).
In my case, it was the fact that I was building under a Release profile. Once I chose Debug from the dropdown next to the Start Debugging button, it started showing my errors in the Error List after a few seconds.
In my case it was since the dependency dll was built for x86, but in the misbehaving project its reference was with processorArchitecture=MSIL
Starting a few months ago I noticed that when a WPF project is out of date, it builds much more slowly than other projects. This seems to have started with Visual Studio 2012, though I'm not positive about that.
So my question is, are there any settings or tools I could use to help diagnose performance problems with the build process? I have enabled extra logging for C++ projects in the past to determine why VS thinks a project needs to be rebuilt when it hasn't changed. Is something like that available for other types of projects?
I have .net application (GUI as well as PowerShell) built against 4.5. My OS is server 2012. When I attach my application to 2013 visual studio, the debugger is not working sometimes. Its not evaluating expression or showing locals (and also watch window/immediate window nothing works - its as if the project is build with release). But I have build with 'Debug' configuration. And as mentioned same thing works when I simply attach with VS 2012 ( yes, I have 2k13 and 2k12 SXS)
Please note that if I attach the same process with the same settings (managed debugging), to Visual Studio 2012 it always works.
I made sure the symbols are loaded (by checking modules tab in visual studio + debug + windows), break points are hit.
Any thoughts on what might be the issue? All the updates are up-to-date as well.
Its kind of annoying to launch vs 2012 just to debug, when I am using VS 2k13 IDE for development.
Regards!
If you are facing the same issue, please look at http://weblog.west-wind.com/posts/2013/Nov/21/Visual-Studio-2013-Could-not-evaluate-Expression-Debugger-Abnormality for details.
Here is the answer which solved for me:
I have set the flag "use managed compatibility mode" in Tools | Options | Debugger | General.
For details, take a look at the link as he explained it nicely as a story :)
Am happy it worked, otherwise I just had to load project in vs 2k12 just to debug it which is annoying.
EDIT on 12th June 2014
I have updated my dev environments with visual studio 2013 update 2 (http://www.microsoft.com/en-us/download/details.aspx?id=42666) (as per Maria's suggestion below) and removed "using managed compatibility mode". I will be testing my apps (ps cmdlets, gui, services) and update you in couple of weeks if the debugger is ok for me.
EDIT on 26th June 2014
I have tested my apps and luckily for me everything is working nicely :). Even the debugger is doing pretty good job with new async/await model. So, see if you can upgrade to 'update 2' - hopefully this works in your environment too?. Thanks to Maria and debugger's team!
Regards.
I deleted all my breakpoints and then it started working, with Visual Studio 2013 Update 1. This was one of the suggestions from the blog post mentioned by Dreamer.
We have released a fix for the issue you are describing in Update 2 CTP 2 of Visual Studio -
Please let me know if that doesn't resolve your issue!
Thanks!
Maria - Visual Studio Debugger
Please note that while the accepted answer probably will fix the problem for now, it's best to be aware of the drawbacks of this solution. Making this change will make VS 2013 use the older style debugger for all you projects. It is a global setting. There are other ways to locally change this for a single project. Please read here for more info on this:
http://blogs.msdn.com/b/visualstudioalm/archive/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013.aspx
We have a custom expression evaluator and our own language and this warning message to change the settings always appears even after I change the project settings to those specified in the blog.
<DebugEngines>{351668CC-8477-4fbf-BFE3-5F1006E4DB1F}</DebugEngines>
Is there something else?
Our clients are using VS2013 pro. I've turned off all the "Enable the Visual Studio hosting process" for all our projects and also added the property to our clients projects. I still see the warning each time I attack to w3wp.exe.
IMPORTANT NOTE: If your project is using the Visual Studio hosting process (the default for many project types), you must disable the hosting process for this fix to correctly change the debug mode. To disable the hosting process go to the Debug pane on the project properties page, and uncheck "Enable the Visual Studio hosting process"
You can resolve this error by applying below points
Sol 1:
1) Restart visual studio and re-open your project.
2) Open your project bin directory and delete DLL of that code where your debugger is not working properly.
3) Then again add DLL reference in the bin directory.
4) Remove all breakpoints.
5) Build project.
6) attach with one w3wp.exe process in attach to process window
7) Enjoy your problem has been resolved.
If above solution is not working then you can try solution that has been provided on bellow link
http://weblog.west-wind.com/posts/2013/Nov/21/Visual-Studio-2013-Could-not-evaluate-Expression-Debugger-Abnormality
I had a similar problem debugging where this error occurred from a return from creating a class. The class initialized fine (using "new classname()") but then it gave the "cannot evaluate expression" error on the return. Though it worked on previous visual studio versions, running on VS 2017 it crapped out.
After a lot of head banging, it turned out that private variables in the class, especially things like arraylists and other classes, needed to be declared with initial values, even if set to null.
Once that was done, everything worked, even though the solution "appeared" to have nothing to do with the problem and gave no apparent clue of where the problem occurred.
We had this problem with PostSharp extension version 5.0.32 with VS2013 Update 5.
Our workaround was downgrade PostSharp extension to version 4.3.19 or disable it.
Set AutoEventWireup="true" on aspx header file. This will turn debug mode on.
I opened my WinRT (I'm using MVVMLight) project in Visual Studio 2013 this morning, and found out that all kind of types even system ones are not recognized saying Cannot resolve symbol 'bool' for example, note that the solution builds, executes and works all fine !
C# :
Even XAML :
I tried many things, closed and reopened the solution, cleared Resharper caches, I even restarted Visual Studio and the PC, but still the same problem, any solution to this problem ?
Update 1 : I tried to Suspend/Resume Resharper from Tools>Options and even delete files from AppData\Local\JetBrains\ReSharper\v8.0\SolutionCaches, and now Visual Studio causes errors too :
Update 2 : I uninstalled/re-installed visual studio, and I still have the same problems
If you have any Xamarin extensions for Visual Studio installed, it is a root of the problem. There are some compatibility problems.
As a possible workaround, you may try a workaround, mentioned in this ticket:
Select 'true' for 'Use msbuild to obtain project references' in
Project Properties (Click on project name in Solution Explorer | Hit
F4) for each project in the solution.
At least, it works for me.
If you can build the solution, but ReSharper marks your code in red - you can write the request here and you will likely get a help.
If you can't build your project then it is not ReSharper's problem. Then we need to find out why your build is broken.
It seems that your project to assembly references are broken.
To understand what's happening here with references during the build, go to Tools -> Options -> Projects and Solutions -> Build/Debug and set the verbosity to diagnostic. Then try to build your project and investigate the output windows in VS (or you can use MSBuild.exe from the command line instead). What you need to find in this large text block is "Resolve Assembly references" or "Expand SDK references" task. These tasks should obtain the valid paths to the assemblies your project depends on. Later on csc.exe should be executed with all these paths as parameters.
You can check whether the paths are correct, do they indicate to the existing binaries or not.
You can also create a new WinRT project template and check if it can build. If it cannot even for the clean project template then it is obviously a system problem, I suppose your platform sdk's are corrupted.
Hope this will help.
I'm working on a VS2010 Solution containing an ASP.NET Website Project and 8 c# class libraries. All projects are set to compile under .NET 3.5
When I set a breakpoint somewhere in the class libraries, the debugger breaks correctly and everything is fine. If I then stop debugging, modify code in the class library, and start debugging again (which of course rebuilds the libraries which were modified) the debugger ignores the breakpoints.
Has anyone else experienced anything like this? I'm lost and it's extremely frustrating to not be able to debug after making even a single line change and rebuilding.
Visual Studio 2010 Ultimate
Windows 7 Professional 64-bit
Be sure that you are killing your webdev server instance. If the breakpoints that are not being hit are in server code a new debug instance won't automatically attach to it.
I encountered this issue - the only way to resolve it was to recreate the solution by importing the existing project into the new solution. Not an ideal workaround but better than googling for an entire day and not being any better off!