I am working on an SSIS package. The package has a script (C# language) task. I need to debug the script task. I set the break point. The script in script editor (Visual Studio) and the task in SSIS package editor, both, show break point in red color - means the break point is enabled. However, when I debug the package the break point does not hit.
The break point has no conditions on it, so I expect it to hit every time the package runs.
I am using Visual Studio 2008 on Windows 2003 R2 64-bit SP2.
After more research and trial-error, found that the SSIS package ignores the breakpoints in a Script Task when debugging on a 64-bit machine. To fix it -
Go to the Solution Explorer
Right click your SSIS project node > Properties
In Configuration Properties > Debugging > Debug Options > Set Run64BitRunTime to False.
After making this change, the breakpoints hit like magic.
I tried all the answers provided here with no success (using VS2015). After some more searching I found this question that is actually an answer which stated that newer C# features / syntax were causing the debugger to not fire correctly.
In their example (and also mine) using string interpolation was causing the breakpoints to not be hit.
Replacing
$"{someVariable} - {someOtherVariable}"
with
string.Format("{0} - {1}", someVariable, someOtherVariable);
did the trick for me.
EDIT
It appears this issue has now been fixed with SQL Server Integration Services Projects, but you need to be running VS2019 to download it.
Update: Guys, I againg lost any ability to set breakpoints (a request to MS)
My previous fixes are below.
Now I'm using logging and tracing instead of debugging.
C# new features (after C# 4.0) are blamed for killing debugging of the SSIS Script Task.
To return the breakpoint capability I do the following.
Remove C# new features
Run my Script Task once, successfully. I.e. without a crash.
Reopen the Vsta Project from my Script Task and put breakpoints there.
At the end, you have to see a red circle on your Script Task.
(Tested in VS 2017.)
Note. I have to mention that debugging works even if your use "Execute Task" only, not "Execute Package"!
Remove C# new features
To remove the C# new features, I can advise you two ways.
First, restrict Vsta Project properties to C# 4.0 (migrated packages may not support this).
Dobule click your "Script Task" to open "Script Task Editor".
Click "Edit Script..." button to open Visual Studio.
In "Solution Explorer" select the project and click the F4 key on your keyboard.
In opened "Properties" window in "C# Language Level" choise "C# 4.0"
Build your project and fix compilation errors.
Secondly, Vsta Projects in old/migrated packages may not show the above "C# Language Level" property.
So you can put your code in a fake project in Visual Studio 2010 and compile it there.
Run it once successfully
After you fix your C#, you have to run your Script Task once successfully.
You may want to put the return statement at the beginning of the Main() method to prevent any real execution.
Sorry, this doesn't always work and I don't realise why but you definitely need to fix your C# in the first place.
At least you will get a working Script Task and can debug it in an old fashioned way (logs by Dts.Events..., exceptions, etc.)
TL;DR
It looks like I even got severe cases when C# new features forced Script Tasks to fail silently with a success completion status.
As an example, add the following to your Script task.
string Bug { get; } // Only getter properties.
//...
var str = $"Now is {DateTime.Now}"; // String Interpolation in C#
//...
var dummy = val?.ToUpper(); // ?. and ?[] null-conditional Operators
And workarounds for this non-complete list:
string Bug { get; set; }
//...
var str = string.Format("Now is {0}", DateTime.Now);
// etc.
What I also do, I build my C# code in Visual Studio 2010. It simply doesn't compile the new .NET features and do not allows .NET Framework versions above 4.0. So far, so good.
Of course, other answers from this SO-question didn't help me.
In my case, none of these solutions worked. I finally got to know that the Resharper was culprit. After uninstalling it, it started working like charm.
In my case, I had to get rid of all features from C# 6: string interpolation, null conditional operators (?., ?(), ?[]) and expression-bodied members (=>) (there might be more in your case). You can check them all here. Of course, the same applies to C# 7 features.
The 32/64 bit changes from other answers didn't help, so I rolled back those and the debugging kept working just fine.
Use System.Diagnostics.Debugger class to add breakpoint programmatically:
System.Diagnostics.Debugger.Launch();
System.Diagnostics.Debugger.Break();
You can check if the debugger is attached or not:
if (System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Break();
Follow these step:
Keep your project or solution opened.
Run your app to hit breakpoint.
Select your project in Just-In-Time Debugger.
I inherited an SSIS package where unfortunately the above answers didn't help.
In the end I found the script task's build properties for debug mode had had the optimize code ticked. Make sure this isn't ticked because for me visual studio would fire up for script debugging and close shortly after without breaking at all.
Pretty obscure but worth a mention.
We hit the same problem recently. For us the solution was to ensure that the script task project was marked to run as with the platform target set to x86.
Edit the script task
Click on the project and select properties
Select to set the platform target to x86
In addition to Jeff's suggestion, also change the Platform Target to "x86" (In the script's properties' Build tab. This FINALLY got me debugging again on a 64-bit system.
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 spent whole day on this and NONE of the solutions mentioned here worked for me.
In my case, the existing project was targeted to SQL Server 2016 which defaults ScriptLanguage Microsoft Visual c# 2015. This doesn't allow debugging in VS 2019. I have to target project to SQL Server 2019 to make debugging work. Of course, I am not going to checkin version change. It's only to debug script. Once script is working, I am going to revert target version to SQL server 2016.
Hope this saves time for someone.
I had the same problem as you #PAS. Using VS 2019 and Target server version 2016.
Just found out that if upgrading SSIS in Visual Studio (going into Extensions->Manage Extensions) to latest version (which now is 3.15) debugging is now working.
My breakpoints refused to hit no matter what I did. I ended up debugging and fixing the issues just using exception throws. Once I had fixed the issues I was having, the breakpoints started hitting!
So my breakpoints would only hit once the code did not experience any runtime issues... which is bizarre.
In my experience, it doesn't matter:
if Run64BitRuntime is true or false
if you build the 32 or 64 bits version of your package
But there is something very important, not mentioned in any other answer: you must run the whole package. If you run a Task or a Container the breakpoint will be ignored.
I'm using Visual Studio 2013, on a 64 bits machine.
I only had one Script component were no breakpoints were hit (I was doing some CRM stuff without needing source/target).
I trid to add a Source componenet with a simple fetchXML (even if I didn't needed it).
Then it worked! :-)
I found out that by copying a Script Component task, the VSTA project as a whole is copied as well. This is what you would expect, but what I did not expect is with that, the assembly name for example is also copied.
Running then Execute Task works fine, but running the whole package actually only runs the first script that was copied and resulted in exceptions being thrown before ever hitting the row processing function.
That was also the reason for me that breakpoints were not being hit.
We are in the process of upgrading from Visual Studio 2013 Update 5 to Visual Studio 2015 Update 1.
Our Solution has many tests and we use NUnit 2.6.4, along with the NUnit Test Adapter for NUnit 2.x.
When running these tests in Visual Studio 2013, they all run perfectly well.
However, when running in Visual Studio 2015 the first 200 odd tests run, then execution stops. I can then select the tests that have not yet run and successfully execute these. I have the latest ReSharper installed in both VS2013 and VS2015 and it happily executes all the tests.
We've been keeping test-coverage details for each release since the dawn of time, and from Visual Studio's test runner it shows me the number of blocks covered. But ReSharper shows us the number of statements covered. Slightly different values, but they'd mess up our charts.
When test execution fails, it creates a Dump file (it also creates some XML files that just seem to show what DLLs I've installed). I can open this and "debug" it, but it simply shows me a line of code that fails, and the call stack shows only [Managed Code], which means I can't identify the actual test that's causing the issue.
The fact that this works perfectly in VS2013 and in ReSharper running in VS2015 suggests that "it's not our fault", but whilst I'd like to think that, it doesn't help me fix this.
Any ideas?
Thanks
Griff
Tracked down the problem. We had one class in our Solution that implements IDispose and one of our Unit tests didn't dispose of that class, it just allowed it to go out of scope.
So because the Disposable object hadn't been disposed, the class' Finalizer hadn't been suppressed. The GC therefore called the Finalizer which in turn attempted to access another object that had also gone out of scope, resulting in an exception that crashed the Test Execution Runner.
Interesting that VS2015 running NUnit 2.x crashes, but the identical setup in VS2013 copes fine.
As an aside, when debugging the DUMP file (see above), I realized that the call stack was irrelevant, I just had to put in some defensive coding in the Finalizer.
I downloaded Visual Studio Community 2015 to try and lean F#. My F# projects compiles without any issues but when I try to launch the console project (even the default console project) Visual Studio just hangs and then freezes. The only way I have to shut it down is to go to the task manager.
Same thing if I try to directly launch the generated .exe file: explorer freezes and I have to go to the task manager to restart it.
All my C# projects work fine...
I have seen a similar behavior before on a machine that had an anti-virus installed. The anti-virus was blocking Visual Studio from running F# code with debugger and disabling the anti-virus resolved the issue.
In general, there are a few ways to run F# code in Visual Studio:
Using F5 to start the program with a debugger (this is the one that the anti-virus was blocking); F11 which steps into the debugger was also not working
Using Ctrl+F5 which starts the program without a debugger - this should work!
By creating an F# script file (Script.fsx), selecting code and using Alt+Enter to run code using F# interactive - this should work too.
Many people do quite a lot of work with F# using F# Interactive, so learning how to use that is a good skill, but to use the debugger, disabling anti-virus should do the trick.
I'm using the latest NUnit, 2.5.9, on Windows 7 64-bit, Visual Studio 2010 Premium, and the projects are .Net 3.5.
The problem is that I attach to NUnit (there is NOT an nunit-agent appearing), and symbols are loading, but my break points aren't being hit. There is no error indicator next to the breakpoint indicating something is wrong.
The first run seems to take some time to start the test, but subsequent runs after that seem to complete almost instantly. I assume because StructureMap (required for the objects i'm testing) has already done its thing and doesn't need to repeat that setup.
Any ideas on how to fix this?
I sort of figured out the answer. I reset all of my settings to the standard Visual C# Development Settings and debugging suddenly works again.
I'm not sure which setting got everything back on the right track; I didn't see a "disable debugging while debugging setting."
I am trying to attach VS2010 debugger to Linqpad so that when I use classes from my c# project I can add breakpoints and have Linqpad execution halt.
But this does not work, Linqpad happily executes and finishes without hitting my breakpoints.
Now, I read a bit on Linqpad and it executes every "query" in its own process, does this in any way fool VS2010 so that the process I attach to is not the one executing my objects?
And if that is the case, is there a way around this so that I can get debugging with Linqpad to work?
Found out that since Linqpad creates a new appdomain for each query window you cannot currently bind visual studio to it directly.
You have to set debugger.break() in your source code to trigger a request for opening a debugger.
This is not the best solution as it means I have to change the source back and forth and cannot use normal breakpoints but it works.
Found a better one my self.
You can not attach Visual Studio to LinqPad and at least trace the code in your VS project.
Unfortunately you cannot trace the linqpad part of the code thiw way.
If anyone should find a better solution, please share it with me.
Found a new thread with a better solution
How to debug LinqPad query in Visual Studio Debugger?