I’ve been working on an integration using SSIS for some time now and we’ve finally gotten to the point that it’s time to push to production. Then this error appeared.
To sum things up rather quickly, I have two packages that handles integration, one per source system, and they read customer info and purchase info which our customer wants to see inside CR… eehhmm, Microsoft Dynamics 365 Customer Edition (powered by powerplatform?). I will go through my steps but the solution is really at the end of the post so, by all means scroll down.
They both worked when I run them in Visual Studio in ”debug mode” and the first one worked very good when deployed to the SQL server which will orchestrate the integration.
When I deployed the second package I got a validation error saying ”The Binary Code for the Script is Not Found” and then it pointed to a script component in the package saying ”script component” (Yes I was lazy and didn’t name it after what it did, which was bad it would seem). I did what most developers do, search the internet and there are quite a few hits on the error.
As you can see, I visited most of these but it didn’t really help since most of them are addressing issues when running the packages inside Visual Studio and that wasn’t really my issue since it was working in Visual Studio but not on the SQL server. These are all saying roughly ”do something in the script code, recompile the script and then recompile the package” with a few variants talking about pre compiled code which doesn’t seem to be a factor any longer.
Eventually I deleted the script component and recreated the script component, which of course made the entire package misbehave since you’re not supposed to do changes to an SSIS package it seems.
This didn’t resolve anything either, one thing I did see though is that the script component ID in the error message didn’t match the ID of the component in the package which looked sort of strange.
Next step was that I created a new solution, imported the package and compiled it. At this point I was sort of thinking that it was silly to have the same name of the packages when they had the same solution so I renamed the package file, again I was lazy and just let it be called package.dtsx.After a move to the server and installation of the package it validated and ran just fine.
Solution: Don’t be lazy and name stuff to what they are doing. Lessons learned: Error messages in Microsoft’s products aren’t always brilliant, even outside Dynamics.
Developer at CRM-Konsulterna