时间戳

首页 > 解决方案 > 现有的 SSIS 包突然无法验证自定义组件 XML

sql-server - 现有的 SSIS 包突然无法验证自定义组件 XML

问题描述

我们一直在使用和运行用于 SQL Server 2014 的 SSIS 包，其中包含自我到达工作地点之前就已使用的自定义组件。我们升级到了 Visual Studio 2017，并且几个月来一直很好。最近——可能与最近的更新一致——Visual Studio ssdt 无法加载这些包，因为有关验证这些组件背后的 xml 的错误。这些包继续在服务器上运行，并且使用这些自定义组件创建新包仍然可以按预期工作。这些包还在 Visual Studio 2013 中打开。我们在代码控制中回到了相同包的早期版本。重新安装了早期版本的 Visual Studio，将 ssdt 工具安装为独立的，但似乎没有任何效果。

由于无法首先加载这些组件，因此无法加载属于这些组件定义的一部分的值，并且在优先约束中对这些值的错误引用存在大量错误或错误，例如：

Error loading CCMI Call Import.dtsx: Error loading value "<DTS:ForEachEnumerator xmlns:DTS="www.microsoft.com/SqlServer/Dts" DTS:CreationName="FolderEnumerator" DTS:DTSID="{FACFAC12-F5E1-4BFE-9768-BF73D8053550}" DTS:ObjectName="{FACFAC12-F5E1-4BFE-9768-BF73D8053550}"><DTS:PropertyExpression DTS:Name="Directory">@" from node "DTS:ForEachEnumerator". C:\Users\..Call Import.dtsx 1

当我删除优先约束中对自定义组件的所有引用时，它将尝试加载没有“损坏”部分的包，但由于这些自定义组件是容器，在某些情况下，这会遗漏大部分已完成的工作。我已经删除了一些它无法在百灵鸟上加载的“坏”值，但是在我删除之前在错误中引用的属性后，它仍然在与容器关联的下一个属性上出错。

我无法打开包，因此无法将组件复制并粘贴到新包中。

有人有想法么？

标签： sql-serverssis

解决方案

在对这些自定义组件的 XML 进行了一些研究之后，我能够解决一些问题，并希望分享它以防它帮助某人，尽管我怀疑我遇到的完全相同的问题会影响许多其他人。

对于自定义 foreach 循环容器，我没有收到任何有用的错误消息，但是当我尝试将其从正常工作的 VS 2013 屏幕复制到 VS 2017 时，我终于收到了一条错误消息，指出（丢失了确切的报价）“缺少服务器目标版本的属性”。然后我发现工作的自定义组件的工作示例有这个从“损坏”的 XML 中丢失的节点：

<TargetServerVersion
          Type="3"
          Value="120" />

我添加了缺失的属性并将值从 140 更改为 120（我们实际定位的版本），它开始工作得很好。

通过类似的过程修复了另一个自定义目的地，尽管错误完全不同。在这种情况下，包实际上会正确打开，但自定义目标将无法正常运行（并且也不再具有自定义图标）。我使用自定义组件创建的工作包的 XML 类似于本例中损坏包的 XML。直到我在一个新项目中创建了一个新包，在其中我立即设置了正确的目标服务器，我才能看到损坏的包和工作包的代码之间的 XML 中的任何变化，它是这样的：

2017 版组件对“UserComponentTypeName”属性的定义要长得多：

<properties>
            <property
              dataType="System.String"
              name="UserComponentTypeName">Konesans.Dts.Pipeline.TrashDestination.Trash, Konesans.Dts.Pipeline.TrashDestination, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b2ab4a111192992b</property>
          </properties>

2016 年的正确版本（我知道，与上一个包不同）有一个更短、更简单的定义：

<properties>
            <property
              dataType="System.String"
              name="UserComponentTypeName">Konesans.TrashDestination</property>
          </properties>

当我用较短的定义替换该属性时，它可以正常工作。

我不知道这些确切问题出现的频率有多高，但是在寻找我的问题的解决方案时我没有看到这样的事情，我想如果有人在 XML 更改方面遇到了不同但相关的问题（也许有人不小心升级了包版本？）它可能有助于为创作过程增添火花并节省一些时间。

推荐阅读