How do I resolve version error between SSIS dtsx file and GAC?

Question

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?

Did you search the dtsx file for the string 7.1.0.9? And any config files? — criticalfix, Mar 05 '13 at 15:54
Notepad says 7.1.0.9 is not found in the .dtsx or config file — nleidwinger18, Mar 05 '13 at 15:59
That does sound odd. Is this a commercial DLL that might be in use by some other part of the system on the server? Even by SQL Server itself? I'm grasping at straws, obviously. — criticalfix, Mar 05 '13 at 16:10

score 0 · Accepted Answer · answered Mar 05 '13 at 17:50

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.)

I'm not sure what the issue was, but I just removed the package from the server and took the dll out of the GAC. Then on my dev machine, I removed the reference to the dll and re-added it in both the package and the windows installer that installs the dll to gac. I then repeated my deployment steps and everything synced up. — nleidwinger18, Mar 05 '13 at 18:24

How do I resolve version error between SSIS dtsx file and GAC?

1 Answers1