SharePointListAdapters: Could not load file or assembly after SQL2012 reinstallation

Apr 29, 2015 at 1:30 PM
Hello,
 
I have an issue with several SSIS packages using SharePointListAdapters, after reinstallation of SQL Server 2012 after an OS upgrade to Windows Server 2012 R2.
 
Opening one of the packages in Visual Studio shows following error:
Error loading myPkg1.dtsx: The managed pipeline component "Microsoft.Samples.SqlServer.SSIS.SharePointListAdapters.SharePointListSource, SharePointListAdapters, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f4b3011e1ece9d47" could not be loaded.  The exception was: Could not load file or assembly 'SharePointListAdapters, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f4b3011e1ece9d47' or one of its dependencies. The system cannot find the file specified..         
 
The jobs are failing with a similar error obviously.
        
After re-installation of the SharePointListAdapters -MSI, I cannot find the 'SharePointListAdapters .dll anywhere within Program Files\SQL Server\110 folder.
Checking GAC with gacutil shows that it’s there, but it’s showing up with a different version number: (Setup Version number in “Programs and Features” is 1.0.0.0)
 
The Global Assembly Cache contains the following assemblies:
  SharePointListAdapters, Version=1.2012.0.0, Culture=neutral, PublicKeyToken=f4b3011e1ece9d47, processorArchitecture=MSIL
 
Any ideas what’s going wrong here? Any help will be greatly appreciated!
Apr 30, 2015 at 2:51 PM
2 additions:
  • I was wrong regarding the missing dll in the 110\DTS folder. It is in place, I just checked on the wrong drive as I had SQL Server installation folders on C and D.
  • I could solve the issue by opening the packages and replacing all the version numbers of the component directly in the xml (Version=1.0.0.0 -> Version=1.2012.0.0) (Other option would be to delete and re-add the components in VS/Data Tools but that would be a lot of work in my situation due to reconfiguration of the adapter components)
Actually this seems to be logical, but as the server already had SQL 2012 before, when the packages were working, I don't understand what happened here...