none
SSIS Script component not Updating .NET framework after 2012 to 2017 Upgrade RRS feed

  • Question

  • Hi Team,

    Currently we upgraded our SSIS packages from  2012 to 2017 version but some of the packages  which has script component or script task has failed with below error message.

      Description: CS0234 - The type or namespace name 'SSISScriptComponentEntryPointAttribute' does not exist in the namespace 'Microsoft.SqlServer.Dts.Pipeline' (are you missing an assembly reference?), main.cs, 10, 35”

     “Description: CS0234 - The type or namespace name 'SSISScriptComponentEntryPointAttributeAttribute' does not exist in the namespace 'Microsoft.SqlServer.Dts.Pipeline' (are you missing an assembly reference?), main.cs, 10, 35”

    We suspect  that changing the Target framework  to  .Net framework to 4.5 inside the script component  would fix the issue but we are unable to  change it. When we changed manually, it is still reflecting the existing .NET framework 4 only after SAVE.  Could anyone suggest how to change it or  do we need  to recreate Script component tasks manually again in the SSIS packages.


    Many Thanks

    Karthi

    Monday, June 18, 2018 1:46 PM

All replies

  • Just a wild guess

    Try opening the packages in SSDT 2017 version by setting the Target Server Version to SQL 2012 . Then change the Target Server Version to SQL 2017 and build the script task code and save the package. Check if it upgrades the references correctly.

    https://blogs.msdn.microsoft.com/sqlgardner/2016/08/17/ssdt-vs2015-gotcha-target-server-version-new-feature/


    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue
    Visakh
    ----------------------------
    My Wiki User Page
    My MSDN Page
    My Personal Blog
    My Facebook Page

    Monday, June 18, 2018 1:55 PM
  • Hi Kathi20,

    You can create a new SSIS 2017 package with the Script Task and check if your package upgraded successfully.

    It's recommended that upgrade your SSIS packages from 2012  to 2014 ->2016->2017 rather than 2012 -> 2017 directly because it may encounter unexpected exception due to lots of codes changed.

    You can also check your assemblies properties inside Script Task project and make sure the version is proper. For example in SSIS 2017:

    Microsoft.SqlServer.ManagedDTS->14.0.0.0

    Regards,

    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.

    Tuesday, June 19, 2018 6:10 AM
    Moderator
  • Hi Zhang,

    Thanks for your Reply!

    As suggested , I have tried upgrading  SSIS packages as below

    1) 2012 to 2014 - Worked fine

    2) 2014 to 2016 - worked fine

    3) 2016 to 2107- failed with the same message as posted earlier

    1)All SQL server assemblies are referring 14.0.0.0 but System,System.Data,System.xml are  still referring .NET framework 4.0 even after upgrading to 2017 , it does not allows changing to higher version of .NET framework in solution properties of Script component.

    2) When we manually replace the existing script component in the package  with new script component  from tool bar it works fine. 

    Please confirm why  Script component is not updating the .NET framework to higher versions while upgrading the SSIS  packages in our scenario.

     

    Tuesday, June 19, 2018 10:11 AM
  • Hi,

    I am having the exact same problem while trying to move my SQL 2016 package to 2017. Changed the targetServerVersion tot 2017 and after that I get error on my Script Task telling me that the script task itself targets ".NETFramework,Version=v4.0" while the dll referenced in the script task point to ".NETFramework,Version=v4.5".

    I tried changed the 'targetServerVersion' in both VS2015 and VS2017. Both with the latest SSDT installed.

    Any help would be appreciated.

    Monday, July 2, 2018 9:50 AM
  • Hi,

    I think I have isolated the problem. We have several packages which were originally created using SSIS 2008 (I hink R2 but not sure). Later they were migrated tot SSIS 2012 and new script tasks (and transformations) were added. We skipped SQL2014 and upgrade straight tot 2016. So far everything worked fine. 

    Now when I upgrade these packages tot sql 2017, the task that were created in the 2008 era all give build errors; the tasks that were created with 2012 or later are fine. 

    My conclusion is that there is something in the markup of the 2008 componenent that won't allow it to be upgraded to 2017 and I think this is something that should be fixed by Microsoft.

    The workaround that works for me is replacing the 'old' tasks with a new identical task (still in 2016). These will be upgrade tot 2017 correctly. I am pretty sure that if you look in the dtsx definition and compare a 2008 task with a post 2008 task you'll be able to figure out the difference and change them accordingly. But that is Always risky.

    Hope this helps. Kind regards.

    Tuesday, July 3, 2018 9:05 AM
  • Hi,

    I think I have isolated the problem. We have several packages which were originally created using SSIS 2008 (I hink R2 but not sure). Later they were migrated tot SSIS 2012 and new script tasks (and transformations) were added. We skipped SQL2014 and upgrade straight tot 2016. So far everything worked fine. 

    Now when I upgrade these packages tot sql 2017, the task that were created in the 2008 era all give build errors; the tasks that were created with 2012 or later are fine. 

    My conclusion is that there is something in the markup of the 2008 componenent that won't allow it to be upgraded to 2017 and I think this is something that should be fixed by Microsoft.

    The workaround that works for me is replacing the 'old' tasks with a new identical task (still in 2016). These will be upgrade tot 2017 correctly. I am pretty sure that if you look in the dtsx definition and compare a 2008 task with a post 2008 task you'll be able to figure out the difference and change them accordingly. But that is Always risky.

    Hope this helps. Kind regards.

    yes

    there's a chance of some assemblies getting upgraded in latest version and so you might have to rewrite them or try using a proper upgrade path (i.e first upgrade to 2012 then to 2016 etc)



    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue
    Visakh
    ----------------------------
    My Wiki User Page
    My MSDN Page
    My Personal Blog
    My Facebook Page

    Tuesday, July 3, 2018 9:41 AM
  • Hi,

    I think I have isolated the problem. We have several packages which were originally created using SSIS 2008 (I hink R2 but not sure). Later they were migrated tot SSIS 2012 and new script tasks (and transformations) were added. We skipped SQL2014 and upgrade straight tot 2016. So far everything worked fine. 

    Now when I upgrade these packages tot sql 2017, the task that were created in the 2008 era all give build errors; the tasks that were created with 2012 or later are fine. 

    My conclusion is that there is something in the markup of the 2008 componenent that won't allow it to be upgraded to 2017 and I think this is something that should be fixed by Microsoft.

    The workaround that works for me is replacing the 'old' tasks with a new identical task (still in 2016). These will be upgrade tot 2017 correctly. I am pretty sure that if you look in the dtsx definition and compare a 2008 task with a post 2008 task you'll be able to figure out the difference and change them accordingly. But that is Always risky.

    Hope this helps. Kind regards.

    yes

    there's a chance of some assemblies getting upgraded in latest version and so you might have to rewrite them or try using a proper upgrade path (i.e first upgrade to 2012 then to 2016 etc)



    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue
    Visakh
    ----------------------------

    No, not really. We did a proper upgrade path but the task that were added while the package was still in 2008 are in a different "state" than task that were added in 2012. Not sure which upgrade didn't work properly.
    We don't need to rewrite anything, "all" we need to do to fix this is created a new task and copy everything from the old one to the new one. This think this is clearly a migration/upgrade issue in 2008-->2012 or 2012--2016 or 2016-->2017 that is not addressed properly.

    Tuesday, July 3, 2018 3:57 PM
  • Same problem, over 100 packages... everyone has at least one script...

    The error Description script is easy to rewrite, many others are not. havent found a solution still.


    Miguel Salles Analista Programador BI

    Tuesday, November 13, 2018 5:37 PM
  • Same problem, over 100 packages... everyone has at least one script...

    The error Description script is easy to rewrite, many others are not. havent found a solution still.


    Miguel Salles Analista Programador BI

    Open a new Integration Services project (in VS 2017), set the Deployment Target to SQL 2016, right-click and add your existing packages. Then, deploy the project/packages to SQL 2017, that worked for us without having to copy/rebuild every script component.




    • Edited by SQLSlacker Wednesday, January 30, 2019 7:05 PM
    Wednesday, January 30, 2019 7:03 PM
  • I have the same problem today and I tried the last advice here and it works very well, so you don't need to create one by one, just click on top of your project change deployment Target to SQL 2012, save it and open again and change to SQL 2016 and save again , works like a champ
    Monday, October 7, 2019 4:25 PM