I have a DLL that I am referencing in an SSIS package. I strong named it and added to the GAC. Everything worked fine on my development machine. Now I am trying to deploy the package. So on the server, I added the DLL to the GAC using a windows installer package that I created to do this. The version of the DLL in the GAC is 7.2.0.1. Then I ran the deployment utility installer for the package on the server. This ran successfully and created the package with the .dtsx file. If I open up the .dtsx file in notepad on the server and look for the reference to the DLL, it says that it is referencing 7.2.0.1 as it should. Then I setup the job to actually run the package. After starting the job, the package runs and fails. This creates an error message in the event viewer that states the package was looking for version 7.1.0.9.
I've looked everywhere for a copy of this DLL with that version and can't find it. I've searched my dev machine and the server and no 7.1.0.9. I'm not sure this DLL ever had that version. All references point to 7.2.0.1, yet it still thinks it needs 7.1.0.9 no matter what I do.
Does anybody have any ideas on what might be wrong here?
When using a custom DLL in SSIS 2005 and SSIS 2008R2, we found that we had to install the DLL both in the GAC and in the .NET Framework 2.0 directory, and that the two versions had to match. IIRC, the version in the .NET Framework 2.0 folder was used by BIDS for package design, and also by dtexec for package validation; the version in the GAC was used for package execution. I believe (but haven't ever tried to prove) that the DLL strong name is compiled into the binary representation of the script task/component.
So I'd start by looking to see if there's a copy of that version 7.1.0.9 DLL hiding anywhere in the .NET Framework 2.0 folder, or anywhere else in the PATH environment variable, on both your development box and the target server.
(Note: I don't know if SSIS 2012 has the same behavior, so this may or may not be applicable to your case.)