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.
Related
Just spent hours pulling my hair trying to work out why my ssis Script Component was not breaking into debugger on hitting a breakpoint.
I searched the web and fund 64 bit setting (Project -> Properies -> Debugging) to be turned off but it didn't help me.
It turns out that if I use string interpolation ( $"{someVar}" ) in my code then debugger does not start.
Once I replaced it with the old string.Format("{0}...", param1, ...) method my breakpoints got hit and I could step through the code.
The code works either way and it is just the debugger that is affected by the newer syntax.
I hope this helps someone.
Indeed, limiting C# Script Tasks to language features of C# 4.0 brings the Debugger back to life. In my case, adding a single null-coalescing operator caused the debugger issue using Visual Studio 2015 (VSTA) on SQL Server/SSIS 2016.
To restrict the Script to C# 4.0 we can enforce a specific Language Level in the Build settings of the Task:
Open the Script Task in question, click the "Edit Script..." button to open Visual Studio (VSTA).
In the Solution Explorer right-click the Project node and select Properties
In the Project window, go the Build tab, scroll down and click the Advanced.. button.
In the Advanced Build Settings window change the Langauge Version from "default" to "C# 4.0".
Clean/Rebuild the Script Task, fix compilation errors.
Finally, exit VSTA, rebuild the project
and then you should be able to debug the C# Script Task again.
Also spent hours pulling my hair out and found out it is indeed due to new Roslyn compiler features not being recognised in older versions of Visual Studio. (I am using VS2015 with an SSIS Script Task)
To get the breakpoints to hit, I opened project in earlier version of VS (2012) and made changes to source code to get it to compile successfully. Once i got it to build i ran in 2012 and voilà! - it hits all the breakpoints. Re-opened project and ran in VS2015 and confirmed it works as intended.
Spent hours too and then finally found your post... thank you sir!
I'm using VS2015 with SSIS Script Task too. For me it was the function nameof() that was responsible for not firing up the debugger. Replacing the function with reflection worked for me: Get string name of property using reflection
I'd like to think the above has cured my issue, but there was another cause/work around that I needed to implement to get script task debugging working again.
In my instance, the issue was the debugger integration used by Resharper, as highlighted by user "Richard T. LaSalle" in the linked solution to the following issue: Could not set BreakPoint in SSIS ScriptTask
TL;DR, If using Resharper, turn off Debugger Integration
Microsoft released an update v3.2 of SQL Server Integration Services Projects where it resolves the issue with Roslyn and other C# language features introduced after .Net 4.5. C# features.
Bad news - this fix is for Visual Studio 2019 only, you have to upgrade your VS to use it.
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.
So the problem is when i try to setup breakpoint on line with Binding markup extension I get error telling me that it's unable to set breakpoint in this location.
Visual Studio
Microsoft Visual Studio Ultimate 2012
Version 11.0.50727.1 RTMREL
Microsoft .NET Framework
Version 4.5.50709
Installed Version: Ultimate
Platform settings
Platform targets are x86 for all except Silverlight ( selection box locked there)
Debug info is set to full everywhere.
Debug settings
Cleaned up and rebuild solution with no errors.
Go to line with Binding press F9 or Debug->Toggle breakpoint and see:
When I had this I error I could usually solve it by doing the following things:
Make sure that Silverlight debugging is enabled: Project properties -> Web -> Debuggers -> Activate the Silverlight CheckBox.
Use the Internet Explorer for debugging. Although it may work with other browsers, I often ran into strange problems like the Breakpoints not being correctly set.
Most important:
Clear the IE browser cache. It is most likely possible that the browser has cached an older version of your Silverlight application and for some reason does not use the latest version of it.
If this works for you, you miht also consider to configure the caching of the temporary internet files to "Never" to make sure that IE always uses the most recent version of your SL application.
You should provide more details for a accurate solution. By experience, you should try:
1 - Check the Configuration Manager and assert all projects are building for Debug, and targeting x86. (x64 has some debugging limitations).
2 - In Project Properties Page > Build > Advanced, assert Debug Info is set to full.
3 - Clean and rebuild your solution. (Worked for me on ASP.NET).
Also, when I couldn't solve this problem, i used a workaround; Create an event handler for DataBind event, and break the code there. Then step into. Eventually you'll step into the xaml file.
Please, mark answer if it helps. Thanks.
The way if i fixed it by selecting Internet Explorer as browser to run into. Then set the binding reakpoint while it was running. Since then it is working well.
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!
Visual studio team system 2008 keeps crashing on me. Sometimes it just freezes, or certain parts of the UI get messed up or a weird popup box saying something about unable to load parameters or saying something else about memory or any other number of things.
it usually happens when I do a "complex" task like go into debug mode or do a search across of whole solution or run a unit tests or something like that.
I rebooted my machine countless time, reinstalled it VS, changed my virtual memory settings, flush my page file on every reboot and anything else i could think of.
It seems like VS runs out memory or something.
I have a powerfully machine with lots of RAM so that's not the issue
any suggestions?
You can always try some standard Visual Studio troubleshooting steps:
Clean the solution
Delete / rename all files in your solution created by VS, i.e. all .ncb, .suo, .user files
Launch Visual Studio with all add-ins disabled: devenv.exe /SafeMode
Reset All Settings: Tools -> Import / Export Settings -> Reset All Settings
Delete HKCU:\Software\Micosoft\VisualStudio\9.0 and then restart Visual Studio
Repair the Visual Studio installation through Add/Remove Programs
You might also check whether there is a hotfix available addressing your issue (e.g. KB960075 sounds like a good candidate for you), or whether you find your problem already reported on the Connect website.
The first step is to uninstall all 3rd party add-ins on Visual Studio. In particular if you have multiple add-ins as they can interfere with each other in unexpected ways and cause crashes. After uninstalling repeat your scenarios and see if this fixes the issue.
If not then it's best to consult the application log and find out why Visual Studio is crashing. The log will contain at least the error code of the crash which can searched on google or reposted here for us to take a look at.
Assuming this occurs with VS up to date with all service packs installed, you might try some of these suggestions. If you haven't tried with service packs, do that first.
What version of Windows are you using? If it is Windows 7, try launching Visual Studio with a compatibility mode and see if that resolves the issue. To do this, make a copy of the normal launch shortcut and go into the Properties dialog and set it to run as Windows Vista.
If this doesn't fix it, then you might also consider:
Checking your PATH environment for any weird settings which might be confusing it, e.g. paths pointing to other SDKs
Any 3rd party VS extensions such as source control, refactoring plugins, wizards etc.
Old versions of .NET or SQL server
Also test if the issue occurs for every kind of project or just certain kinds, e.g. does it happen for all projects? Does it happen in C++, C#, VB.NET projects etc.
You can also attach a debugger to Visual Studio, to see what it's doing. Sometimes a particular .sln will trigger bad behavior or more likely, some third-party add-on.
If you believe that you've gotten VS into a wired state, you can try the following command line switches
devenv.exe /ResetSettings (This will reset the visual studio settings to the defaults)
If that doesn't help, as a last resort, you can try
devenv.exe /ResetUserData