Some quick solutions if you don’t want to read the story:

  1. Check if package variables referenced in script task are correct
  2. Check if package variables are being set correctly outside of the script task
  3. Check if the script task’s references match up with the server’s framework
  4. My issue: check if you have permissions

Back to my story:

The other day, one of the packages I maintain broke in nearly every region it was deployed to. I’m thinking “Omg, why?” since this process has never failed in the years it has been implemented. So, I looked at the log to find the descriptive error message : Exception has been thrown by the target of an invocation:

I’m thinking, “Cool, I’ve seen this before, it should be easy“. So I go through the code to trace it to where it was bombing out, then I go through the routine of debugging the common issues:

  1. Check if package variables referenced in script task are correct – nope!
  2. Check if package variables are being set correctly outside of the script task – nope!
  3. Check if the script task’s references match up with the server’s framework – nope!

Nothing seemed to be off in the cases. Eventually, I assume that it has to be a security issue – because that seems to be the solution to everything for me. I run the process in a dev server to find that everything is fine. Now I’m like “Seriously?!“.

Frustrated, I end up wrapping the code in a try catch to print out the error and deploy:

Ah, I knew it! Unauthorized access:

Short story, I looked at previous versions of the directory to find the security had changed. I end up getting permissions added for the users, and ta da! Worked like a charm.

Lessons learned:

  1. Think outside the box. How the heck would someone think it’s a security issue from “…target of invocation”?
  2. Better error handling
  3. Don’t forget to rollback the changes you deployed to quickly find out what was going on since it’s not really good code and you could get in trouble for it

 

Hopefully that helps! Happy coding!

2 thoughts on “SSIS – Script Task: Exception Thrown by Target of an Invocation

    1. Hi Michelle,

      Thanks for mentioning that. To be honest, I wasn’t even sure if anyone stumbled upon my posts. To answer your question, the “booFire” variable is a boolean value that is fed into Dts.Events.FireInformation() method for the fireAgain parameter. In most cases, I set it as false because my Script Tasks are usually simple. What this means is that it will suppress any further events.

      Click on this sentence to find more information on the Dts.Events.FireInformation().

      Click on this sentence for a great explanation on why you should or shouldn’t set that value to true or false.

      I will update the post when I get the chance. Thanks for the feedback.

      John Xiong

Comments are closed.

Back To Top