sql-serverssisetlsql-server-2016ssis-2016

SSIS Script Component not working when deployed. Complains about ComponentVersionMismatchError


A package with a Script Component that runs fine on SSDT (Visual Studio 2017) does not run when deployed to SQL Server 2016. It throws a ComponentVersionMismatchException.

So, other packages work fine. This one has a data flow with a Script Component destination. When I first started developing the project, I hadn't adjusted the target from SQL 2017 down to SQL 2016. I developed everything and got it to run from SSDT. I'm using a .ispac file to deploy. When deployed, it's throwing the ComponentVersionMismatchException. Here's what I've tried to get a script component to run:

  1. Change the target to SQL 2016. Failed.
  2. Make a minor change and ensure that the script is recompiled. Failed
  3. Ensure that Visual C# 2015 is selected. Failed.
  4. Make a duplicate of the package, and delete the script component. This succeeded.
  5. In the duplicate, just add a new empty script component as destination. Failure again.
  6. Delete the data flow task and rebuild with empty script component. Failed.
  7. Create a package completely from scratch and recreate the data flow with the same source and empty script component. Failed.
  8. I tried creating a new project entirely, set the target to SQL 2016, and created a similar dataflow just with a table as source and an empty script component as destination. Still failed.

I would expect that a brand new project targeting SQL 2016 with a script component that does nothing should be able to execute on the server. I'm rather lost at this point.


Solution

  • Given what Piotr said AND that I had already updated to the latest version of the VS shell/SSDT for VS2017, I tried installing SQL Server Data Tools for VS2015.

    Visual Studio 2015 was able to deploy directly to the (local) server and the packages deployed from the VS2015 version did not exhibit the execution issues that the ones from VS2017 did.

    Given that SSDT for VS2019 has been released, it might be worth trying that version out in the future.

    Looks like it is a still unfixed bug in SSDT for VS2017.