当 SSIS 首次出现时，有大量关于所有问题的笑话和帖子，以及每个人如何认为 DTS 更好，他们真的必须转换吗？多年来，我开始欣赏 SSIS。它是一个非常强大和有用的工具，可以做一些了不起的事情。当然，最近版本的 SSIS 已经显示出巨大的改进。不幸的是，我在开始时遇到的一些最大的抱怨今天仍然存在。其中之一就是它是如何特定于版本的。在执行方面，情况还不错。dtexec 的更高版本将“临时”升级软件包以便在其版本中运行它。但是，在编辑时，根本没有向后（或向前）兼容性。如果您在更高版本的工具（Data Tools 或 Business Intelligence Development Studio）中打开较低版本的 SSIS，则会升级包。一旦升级，就再也回不去了。降级软件包的唯一选择是您是否有备份或较旧的副本。而且您当然无法打开比您打开它的工具更高版本的 SSIS 包。
如果您支持多个版本的 SSIS，这可能会导致一些问题。如果您有几十个 SSIS 包，而您没有某种命名或放置方案来确保您知道每个包的版本，那么您很容易遇到麻烦。假设您正在帮助一位同事处理他们的 SSIS 包。他们安装了 SQL 2008，这是当前运行的服务器版本。您打开它但忘记了您实际上正在运行 SQL 2012 的 Data Tools。您解决了他们的问题，但您没有注意，也没有注意到“我已经自动升级了您的包”消息。你的同事很兴奋！直到第二天他们让你知道他们在凌晨 3 点被叫醒，因为他们的包裹刚刚开始抛出错误消息。关于错误版本的事情？哎呀。
在 DTSX 文件中必须有一个标签，说明它的版本，并且由于 SSIS 包以 XML 格式存储，我们应该能够很容易地找到它。如果您在文本编辑器（或 IE，或任何其他 xml 查看器）中打开 DTSX 文件，您可以在包顶部附近找到一个标签 PackageFormatVersion。该属性将告诉您这个包也属于哪个版本的 SSIS。下面我有一个漂亮的小表，其中包含每个 SQL 版本的 PackageFormatVersion 以及每个版本的 Visual Studio 的一个很好的奖励。
| SQL 版本 | 建造 ＃ | 包格式版本 | Visual Studio 版本 |
| 2005年 | 9 | 2 | 2005年 |
| 2008年 | 10 | 3 | 2008年 |
| 2008 R2 | 10.5 | 3 | 2008年 |
| 2012年 | 11 | 6 | 2010 或 BI 2012 |
| 2014年 | 12 | 8 | 2012 CTP2 或 2013 |
| 2016年 | 13 | 8 | 2015/2017 |
| 2017年 | 14 | 8 | 2017年 |
