SharePoint List Adapter on 2012

Jan 22, 2013 at 5:56 AM


Has anyone noticed that nobody has given a decent response to how to get the SharePoint list adapters installed/working on SQL 2012. Is there actually a solution? Very frustrated. We have a tight deadline to migrate over to SQL 2012 and this is holding us up big time.

Jan 22, 2013 at 9:23 AM


I have eventually had success getting the SharePoint list adapters working in SQL 2012:

  1. Upgrade the package from SQL 2008 to SQL 2012. I did this by opening the project in Data Tools and following the Upgrade wizard
  2. You will get a nasty message about the SharePoint list component
  3. If you look in C:\Program Files\Microsoft SQL Server\100\DTS\PipelineComponents you will see SharePointListAdapters.dll
  4. Re-install the SharePointList adapterc
  5. The same dll will now also exist in C:\Program Files\Microsoft SQL Server\110\DTS\PipeLineComponents
  6. Open up Data Tools and the package that has been upgraded
  7. You will notice an error condition on the data flow component that contains the task for the SharePoint source on the control fow
  8. Switch to this data flow component
  9. Right click and select SSIS Toolbox
  10. Important - click on the Toolbox panel and choose Refresh Toolbox
  11. Hopefully you should see both the source and destination components in the common section of the toobox
  12. Unfortunately you have to redo the settings for the SharePoint component. Its a bit of a pain but a bit of copy and paste from the old SQL 2008 solution (which you should have backed up before the migration) gets the package working in a couple of minutes.

If anyone has a better way of doing this - please respond


Jan 23, 2013 at 1:48 PM

Is it only in an upgrade condition that the SP Tools are not found?   The upgrade between versions was always a little weird.  I remember people having the same issue for 2005 -> 2008.  Since the definition for the files has changed so dramatically for 2012, I'm not quite sure if there is an easier way to do the migration (I do not have a lot of experience with ssis 2012)

Jan 23, 2013 at 1:56 PM

Thanks howetj, I added your instructions to the documentation section to hopefully help others.

Mar 19, 2013 at 2:27 AM
I had this adapter previously installed with VS 2008, and had issues making it work by simply Upgrading/Repairing the List Adapter. VS2010 would not even be able to upgrade the SSIS Package: The wizard would fail and the package would be unusable.

I had to completely remove the List Adapter from Add/Remove programs, and re-install it. Then I was able to run successfully the Upgrade Wizard on the SSIS Packages and work with them.

P.S. Love the adapter btw ;)
Sep 17, 2013 at 3:45 PM
Hi All. if you want to change the XML itself you can do a find replace on the Entire Solution:

Look for:

Microsoft.Samples.SqlServer.SSIS.SharePointListAdapters.SharePointListDestination, SharePointListAdapters, Version=,

Replace with:

Microsoft.Samples.SqlServer.SSIS.SharePointListAdapters.SharePointListDestination, SharePointListAdapters, Version=1.2012.0.0,

Do the same with the Source, i.e.
Microsoft.Samples.SqlServer.SSIS.SharePointListAdapters.SharePointListSource, SharePointListAdapters, Version=,


Microsoft.Samples.SqlServer.SSIS.SharePointListAdapters.SharePointListSource, SharePointListAdapters, Version=1.2012.0.0,
Oct 8, 2013 at 1:38 PM
After about a day struggling with this, I finally discovered that:

3.If you look in C:\Program Files\Microsoft SQL Server\100\DTS\PipelineComponents you will see SharePointListAdapters.dll

This is not entirely accurate, at least in the case of installing SQL Server 2012 on our SSIS server, and then installing the SharePointList Adapters beta for 2012. It turns out that there apparently is only a 32-bit SharePoint adapter, and not a 64-bit one. Most of our SSIS packages run with the 64-bit version of DTExec, which "lives" in the tree as shown above. However, the only place I found SharePointListAdapters.dll actually installed was in C:\Program Files (x86)\Microsoft SQL Server\110\DTS\PipelineComponents.

Consequently, I had to change the .bat file which our job scheduler runs to execute the DTExec from the 32-bit location. Which, of course, explains why I was always getting an error about not finding an SPCRED adapter when I ran the package the way it has in the past, from the 64-bit DTExec.