最近我尝试在我们的生产环境中部署SSIS包，在遇到一些错误后，我通过从服务器（而不是从部署文件）导入到SSDT来检查包的内容。我发现真的很有趣 - 来自Script Task的C＃代码（我们只有一个脚本任务）消失了，只有模板代码甚至是你在将Script Task添加到包时看到的注释，看起来它不是曾经由任何人编辑过。
我问我的同事他是否可以在同一台服务器上而不是我部署相同的项目，并且它有效，代码就在它的位置，一切都顺利进行。
可能导致此行为的原因是什么？我们都是服务器管理员，我们都有SQL Server的sysadmin权限，我们不知道他拥有的任何权限，我不知道。
编辑：我们都在部署相同的.ispac项目部署文件，我们都没有在“生产就绪”之后对其进行编辑。我们也以相同的方式部署它 - 双击.ispac文件，并使用Integration Services部署向导。 包在不同的服务器上准备。答案 0 :(得分：0)
我遇到了一个非常类似的问题。之前的帖子可能已被删除，但我可以证明SSIS包中的进程脚本任务正被替换为空或默认任务。我怀疑SQL Server \ 120 \ DTS \ Binn目录中的版本或dll不兼容。
我们目前使用集成了SSDT的Visual Studio 2013 Professional进行开发（未使用shell或独立版本）。开发在带有SP1的Windows 7 Enterprise 64位计算机上进行。使用SSDT在本地进行所有测试都很好。部署到服务器后，测试按预期工作。服务器是我认为问题源自的地方。我们部署到在Windows Server 2012 R2上运行的SQL Server企业版。 Microsoft SQL Server 2014（SP1-GDR）（KB3194720） - 12.0.4232.0（X64）。 ispac是从SQL Server Integration Services目录中的SSMS导出生成的。然后将ispac部署到另一个站点。
原来，该网站已将其部署到SQL Server Developer 64位实例。从理论上讲，这应该可行，但是当将已部署的项目导回到此站点的Visual Studio SSDT独立实例（未嵌入Visual Studio Professional）时，所有Process Script Tasks都替换为Process Task的默认实例。 在内部再现场景时，在SQL Server 2014 Developer 64 Bit上作为部署站点，然后将其导回到新的Visual Studio SSDT项目中，Process Scripts确实已被替换。在创建新的Visual Studio SSDT项目并从Enterprise Edition导入它们时，Process Scripts就在那里。
对于我们来说，它似乎是SQL Server版本之间的强烈关联，或者它们不同的事实。