如何通过命令行构建 SSISDeploymentManifest
作为我的自动构建的一部分，我需要有几个用于部署的工件。其中之一是我在 Visual Studio 2008 中构建 SSIS 项目时创建的 SSISDeploymentManifest 文件（VS 2010 不支持 SSIS/BIDS）。
我正在尝试找到一种从命令行执行此操作的方法，但正常的东西不起作用（带有 /Build 和 /Project 标志的 devenv...）
有谁知道如何完成此操作？
注意：我正在使用 TFS 2010 进行构建
其他注意：我没有尝试部署或运行 SSIS 包。我只需要构建 SSISDeploymentManifest 文件，以便当其他人“祝福”该构建时可以轻松部署它。 （这意味着 dtutil 和 DTEXEC 不是我正在寻找的。）
As part of my auto build I need to have several artifacts for deployment. One of them is the SSISDeploymentManifest file that is created when I build my SSIS project in Visual Studio 2008 (VS 2010 does not support SSIS/BIDS).
I am trying to find a way to do this from the command line, but the normal stuff is not working (devenv with the /Build and /Project flags...)
Does anyone know how to get this done?
NOTE: I am using TFS 2010 to do the building
OTHER NOTE: I am NOT trying to deploy or run the SSIS package. I just need the SSISDeploymentManifest file built so that when someone else "blesses" the build it can easily be deployed. (This means that dtutil and DTEXEC are not what I am looking for.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不知道你是否找到了解决这个问题的方法。我一直在尝试做完全相同的事情，但遇到了同样的旧“哦，但你应该使用 xyz”答案，但没有帮助。最后，我只是使用 BIDS 构建了一次部署清单，然后将其复制到我的解决方案目录中。它永远不会改变（至少对于我们的包来说不会），并且由于“build”命令实际上除了将 dtsx 和配置文件复制到文件夹中并为部署清单编写 xml 之外，所做的事情并不多，因此有意义只需让我的构建过程复制这些文件本身，包括我预先构建的清单。
这还允许我从清单文件中编辑敏感信息（即我的域帐户名和域名本身）。唯一的事情是，如果你显着改变你的包（例如重新命名），你将需要使用 BIDS 生成一个新的清单，但这是我能想到的最好的，我无法证明更多的时间花在搜索上另一种方式。
Don't know if you ever found a way round this. I've been trying to do exactly the same thing and encountering the same old "Oh but you should be using xyz instead" answers which aren't helpful. In the end I simply built the deployment manifest once using BIDS and then copied it to my solution directory. It never changes (at least for our packages it doesn't) and since the 'build' command doesn't actually do more than copy the dtsx and config file into a folder and write the xml for the deployment manifest, it made sense to simply have my build process copy these files itself, including my pre-built manifest.
That also allowed me to edit out sensitive information (i.e. my domain account name and the domain name itself) from the manifest file. The only thing is if you change your package significantly (re-naming it for example) you'll need to generate a new manifest using BIDS, but it's the best I could come up with and I couldn't justify any more time spent searching for another way.