locked
Differnece between .ispac and SSDT deploy RRS feed

  • Question

  • Came across an interesting scenario, on how the jobs behave using different methods of deployments. .ispac file deployment leads to a failure on script task, whereas if i deploy directly from Visual Studio there is no failure on same job and same task.

    Here are the versions installed on the system, any thoughts...

    I am more of looking at pointers as to how are the deployments different and how does the packaging change, i already have a workaround on how to fix the issue so not looking at workarounds just need to understnad conceptually how the 2 deployment mechanism differ.

    Development Tools:  Visual Studio 2015, SSDT - 14.0

    SSIS/ Application Server: SQL Server 2016- Enterprise Edition (in turn that means SSIS 2016).


    Abhinav http://bishtabhinav.wordpress.com/


    • Edited by AB82 Tuesday, September 12, 2017 5:50 PM
    Tuesday, September 12, 2017 5:46 PM

All replies

  • Hi Abhinav,

    What is the error you are getting?


    Arthur

    MyBlog


    Twitter

    Tuesday, September 12, 2017 6:29 PM
  • So i am testing this with a package 1 which has a script task on it. This package was in SSIS 2012 we migrated it to SSIS 2016 and now trying the same package 1, using these 2 deployments.

    When I deploy using .ispac this is what i get for the script task

    Version 15.0 script that is not supported in this release of integration services

    There is no error when same package 1 is deployed using SSDT, we are using SQL server deployment in case that wasnt clear,

    Again we know a workaround such that we could make our packages work, but seeing the error there is definitely a difference in the way .ispac deployed and the way the SSDT deployment work. and my intention is some guidance around finding that difference


    Abhinav http://bishtabhinav.wordpress.com/



    • Edited by AB82 Thursday, September 14, 2017 5:39 PM Addin ghe error message in content
    Tuesday, September 12, 2017 6:36 PM
  • I suspect the error will surface up when you actually run the package.

    Anyways, the Script needs to be addressed

    Now we know one deployment option actually tries to compile it versa another does not.


    Arthur

    MyBlog


    Twitter

    Tuesday, September 12, 2017 9:15 PM
  • Hi AB82,

    What are the version of SSDT/SSMS are you using?

    If you are using SSDT 17.x to develop the SSIS 2016 or before package, it may encounter the issue that Script Task does not work when deploying .ispac file in SSMS(17.x). As you know, currently, we could be able to use SSDT to deploy the project as a workaround.

    Personally, I don't think there are obvious difference between them. They should call the same wizard application (ISProjectWizard.exe) and they use same version of .NET Framework for VSTA. And as far as I know, if we save the package, it will compile the package automatically. 

    Anyway, for this issue, it's more likely caused by the SSMS/SSDT itself (I remember the Scrip Task works when I deploy the .ispac file in SSMS 16.x). You could submit a request/bug to Microsoft

    Thanks,

    Pirlo Zhang  


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.



    • Edited by Pirlo Zhang Wednesday, September 13, 2017 8:22 AM
    • Proposed as answer by ArthurZ Thursday, September 14, 2017 5:58 PM
    • Unproposed as answer by AB82 Thursday, September 14, 2017 6:55 PM
    Wednesday, September 13, 2017 7:43 AM
  • Hi Zhang,

    Thanks for your response. The versions used are as below: -

    SSDT

    The release number: 17.2
    The build number for this release: 14.0.61707.300

    SSMS - V17.2 (14.0.17177.0)

    As suggested, I will try installing SSMS 16.x and see if i could get past the issue.

    Thanks.


    Abhinav http://bishtabhinav.wordpress.com/

    Wednesday, September 13, 2017 5:47 PM
  • You MUST use the ISDeploymentWizard.exe from SQL 2016 to deploy SSIS packages to SQL 2016.  Otherwise, you will receive that error message.

    Wednesday, September 13, 2017 5:53 PM
  • Thanks i think we made some headway using this...... so this is what is happening maybe this info help others......SSMS 17, installed with it a folder called as 140 i.e. C:\Program Files (x86)\Microsoft SQL Server\140, this is the exe "ISDeploymentWizard.exe" used once you double click the .ispac file. Supposedly this is for SQL 2017.

    The correct version to be used is inside 130 folder--> this corresponds to SQL 2016 installation. when we manually click the ISDeploymentWizard.exe from this folder all things went well...... alternative could be to rename the ISDeploymentWizard.exe inside the 140 so double clicking the .ispac would force execution for next folder in this case 130.


    Abhinav http://bishtabhinav.wordpress.com/

    Thursday, September 14, 2017 5:36 PM
  • So this is what Pirlo guess is the issue - you using a newer SSDT BI buld than necessary 

    Arthur

    MyBlog


    Twitter

    Thursday, September 14, 2017 5:59 PM
  • Yeah i think pirlo got the issue right, though your next statement SSDT build and we using wrong version is not given that

    We are using the correct SSDT version which goes with Visual STudio 2015, the problem is introduced with SSMS 17.x installation, as this is a separate install outside SSDT, i am not sure why MS is shipping both of these as separate installations.

    My main question about difference between the .ispac installation and installation from SSDT is still unaswered though i have reasons to believe that both trigger the ISDeploymentWizard.exe,, the difference being SSDT uses the 130 folder always whereas .ispac used the latest folder i.e. 140 in this case


    Abhinav http://bishtabhinav.wordpress.com/


    • Edited by AB82 Thursday, September 14, 2017 7:03 PM
    Thursday, September 14, 2017 6:55 PM
  • Just un-install, no real need to use it. why shipping is to test SQL Server 2017

    Always read the label ™


    Arthur

    MyBlog


    Twitter

    Thursday, September 14, 2017 10:43 PM
  • Thanks! We had a likewise issue with ODBC Source components, with a MS support ticket open for more than we week untill I found this suggestion.

    Using the ISDeploymentWizard.exe from \Microsoft SQL Server\130\DTS\Binn explicitly in our scripts solved the issue, as did uninstalling SSMS17 and replacing with SSMS16.5

    Thanks!

    Wednesday, September 27, 2017 4:13 PM