O objetivo desta pergunta é documentar minha resposta ao que parecia ser um problema estranho ao alterar a versão de destino do SQL Server de um pacote SSIS criado em algumas versões mais antigas do SSIS anteriores a 2012 que usam tarefas de script.
Um pacote SSIS originalmente criado no BIDS 2005 ou 2008 não teve problemas quando atualizado por meio das várias versões do BIDS/SSDT ao longo dos anos. Mesmo agora, quando o pacote foi atualizado para SSDT e direcionado ao SQL Server 2016, tudo ainda funcionou como sempre, além de poder aproveitar os recursos mais recentes do SSIS (partes do pacote, parâmetros do projeto etc.) /Visual Studio para o mesmo SQL Server de destino. SQL Servers com SSIS instalado que foram atualizados para 2016 ou 2017 pareciam não ter problemas com pacotes que estavam no MSDB ou no repositório de pacotes, pois os trabalhos continuaram a ser executados conforme esperado após a atualização.
Então, como parte da rotina normal de atualização, decidiu abrir um pacote SSIS e atualizá-lo como antes com as alterações anteriores do SSDT. Nas alterações anteriores do SSDT, uma versão funcionava para uma versão específica do SSIS. Depois que eles introduziram a capacidade de direcionar algumas versões anteriores do SSIS, esse recurso parecia funcionar conforme o esperado. Achei que as coisas seriam as mesmas com as versões mais recentes do SSIS e SSDT.
No entanto, depois de alterar a versão de destino para o SQL Server 2017 no SSDT, algumas coisas apareceram que o SSDT não detectou/corrigiu ou não conseguiu lidar por algum motivo. Alguns dos problemas que encontrei foram:
- Não é possível alterar a versão de destino do .Net Framework, pois ela sempre volta às configurações originais nas propriedades da tarefa de script
- Apareceriam erros como "'Dts' não é membro de 'Microsoft.SQLServer'", "Tipo 'Microsoft.SqlServer.Dts.Tasks.ScriptTask.VSTARTScriptObjectModelBase' não está definido", "Falha ao migrar scripts contidos no pacote para o formato VSTA 14.0. Mova os scripts para uma nova tarefa de script." e "O tipo 'Microsoft.SqlServer.Dts.Tasks.ScriptTask.SSISScriptTaskEntryPointAttribute' não está definido."
- A criação da tarefa de script falharia e um dos erros seria "A referência primária "Microsoft.SqlServer.ScriptTask, Version=14.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" não pôde ser resolvida porque foi compilada no arquivo ". NETFramework,Version=v4.5" estrutura. Esta é uma versão superior à estrutura de destino atualmente ".NETFramework,Version=v4.0" e o outro erro que eu veria era "Namespace ou tipo especificado no Imports 'Microsoft.SqlServer .Dts.Runtime' não contém nenhum membro público ou não pode ser encontrado. Verifique se o namespace ou o tipo está definido e contém pelo menos um membro público. Certifique-se de que o nome do elemento importado não use nenhum alias."
O bom é que alterar o destino de volta para o SQL Server 2016 parecia funcionar e eu poderia continuar editando os pacotes como antes sem erros e a compilação funcionaria conforme o esperado, mas a má notícia é implantar o pacote de 2016 em um servidor SSIS de 2017 não foi convertido como fez durante a atualização do SQL Server. Então, como eu poderia atualizar os pacotes para o SQL Server 2017 e não ter esses problemas que impedem isso?
A principal fonte do problema são as tags alteradas no esquema SSIS que 2016 e anteriores foram tratadas sem problemas. Eu tive que visualizar o código do pacote SSIS para verificar as diferenças e o SSIS 2017 parecia ser um pouco mais rigoroso quando se tratava do esquema no nó PropertyGroup da tag Project para as tarefas de script.
Aqui está a aparência de uma tag que tinha erros:
A correção que parecia resolver metade dos meus problemas foi adicionar as entradas ausentes para que as entradas acima agora se parecessem com as novas entradas do código abaixo (que são depois
</ProjectGuid>e antes</PropertyGroup>) são:Veja como ficou depois de adicionar as alterações:
Fazer isso não corrigiu o problema com a incapacidade de alterar o destino do .Net Framework, então tinha que haver algo mais, então examinei o código e encontrei o problema. No código eu encontrei o seguinte depois
</ProjectExtensions>:Como agora eles estavam localizados no PropertyGroup principal da tarefa de script, eles são considerados redundantes, portanto, não são mais necessários no local antigo. A exclusão dessas entradas corrigiu a outra metade do problema. Depois de fazer isso, não só consegui alterar o destino do SQL Server para 2017, como também consegui alterar a versão do .Net Framework e ela não foi revertida. Além disso, as compilações foram capazes de compilar com sucesso novamente.
Resolver o problema dessa forma foi mais fácil do que tentar abrir todos os pacotes e criar manualmente uma nova tarefa de script, copiando a lógica da antiga para a nova, certificando-se de que as variáveis e referências eram as mesmas e excluindo a tarefa antiga, entre outras coisas. Esse processo levaria muito tempo, especialmente se houver muitos pacotes para percorrer.
Espero que você ache isso útil se você se deparar com esse problema.