SSIS 2012 - script task won't run second time (unless debugging)

Question

I'm getting a really tough error in SSIS 2012. I am just running in SSDT.

I have a script task inside a For...Each block.

It runs fine the first time it is reached.

The second time it is reached, I get a generic "Exception thrown by object of invocation error", attributed to the script, at the script task.

It is a small script, all inside Main(), and with a Try...Catch block.
I am not hitting the Catch, which adds custom text.
It seems like it is behaving as if it never enters the Script...

except
if I actually set a breakpoint in it.... in which case it runs fine,
whether I step line-by-line or just hit F5.

I know this isn't terribly specific, but I'm hoping someone has seen this.

Has anyone seen anything like this before?

---

As mentioned, I have tried debugging (obviously), but then I don't get any error.

I have tried changing my variable access from the basic to through VariablesDispenser.LockOneForRead, in case it is something with variables that happens before Main(). I think I got all the places the variables are used in the loop, but that didn't help.

Answer 1

Because this was so killer, I'm going ahead and answering it.

It was actually an un-"declared" variable, but in my Catch block.
Copy-paste error :/

I was using a variable as
"Dts.Variables["TaskName"]"
in the Catch block, but I had not selected it in the Script Task window.

I have no idea why it didn't give me the specific "not found in collection" error.
I have certainly run into this before and seen that. :/

Answer 2

Just ran into that and it was a bear to figure out.

What it was was that I had a static variable (actually a singleton class) defined. Evidently, SSIS does NOT re-initialize a program on second and subsequent invocation, but holds the image and simply re-launches at its entry point.

My Singelton class (and I've verified for several static variables now) does NOT get re-initialized. It still exists. The issue was that it was created with the Dts Variable set that existed on first invocation of the script. Since it's "self" values was not null it never re-instantiated.

When I recognized what was happening, it was of course easy to fix, but one gets used to a stand-alone environment where every program instance has its static values null or set with a static initial value. We presume automatically that a new "run" of the program will likewise have its global spaces "clean" .... in point of fact I'm fairly sure that was what I read as part of the C# "contract" that I'd never need to worry about historical cruft in memory spaces for variables.

Well it turns out that that "contract" is about as good as any Microsoft will make you sign.

It's actually a mixed blessing. Knowing that it happens I can use it to save a lot of overhead in scripts invoked in loops ... but as it's not well, or perhaps un- documented I'll need to be careful to have work-arounds and default loading tests if it turns out not to be true in some future release or version.

(Be gentle in your criticism... I'm new to SSIS. Not so new to program paradigms. CICS mainframe programs would re-init global spaces unless you did things in the linkage to signal it not to ... if you're going to re-invent wheels at least look at old wheels).

-- TWZ