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.
Related
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
The Context
We'd like to modify Roslyn and be able to debug it while compiling with it. Pre-VS2015 release, doing this was a painful process that didn't flow very well.
Our goal is to develop a C# variant compiler.
The Dream
Pre-VS2015, executing and debugging your modded Roslyn required the opening of a second VS IDE (experimental) set to use your modded Roslyn. This process wasn't straight forward to setup properly, and oftentimes would break your VS2015 installation.
Post-VS2015, is there a better setup and process possible to modify and debug Roslyn?
I have installed Visual Studio 2015 but it looks like I need more required bits. After that I'm unsure how to run the tests and try the changes in VS2015.
We have our current documented process of testing your own versions of Roslyn here. As long as you're on Visual Studio 2015 Update 1 or later (where we did all the work to support this), everything should work.
The executive summary of those instructions is if you now enlist into Roslyn, you can choose the "VisualStudioSetup" project and just hit F5 to run. That builds to .vsix files in your build directory you can also install. If you want to, there's a CompilerExtension project that produces a compiler you can build with.
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 had Visual Studio 2010 installed on my Windows 7 desktop, that I was using primarily to debug ASP.NET solutions. Everything was working great, until one of the Windows updates installed a new version of the .NET Framework. Now I get the following message when I try to place a breakpoint and then do a "debugger step" in my C# code:
To make matters worse, it doesn't happen all the time. I tried to find any pattern, but the best way I can describe it is sporadic.
Any idea how to fix this?
I just got this in Visual Studio 2015. I was debugging on a separate thread, hit the breakpoint but could not continue. A reboot did not fix it.
I deleted all of my breakpoints, reset the two that I actually wanted and it works!
Can I suggest you try using the resharper test runner. I have also been hitting this error a lot in VS2017 15.5.2 I have found its something to do with the VS test system.
Even though this solution is a product recommendation (I don't work there) it solved my issue and I was able to get things debugged.
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!