如何在 TFS2010 中成功构建后签入项目/解决方案 (dll) 的输出
只是想知道在成功构建后检查项目或解决方案的输出的推荐过程。
例如，Build 与公共库相关。发布更改我希望将其签入到已知位置，以便其他解决方案可以参考。
一些示例可能是
- 自定义工作流活动
- 直接调用 TF exe
Just wondering on the recommended process of checking in an output of a project or solution post a successful build.
For example the Build relates to a common library. Post a change I want that to be checked in to a known location so other solutions can reference.
Some examples might be
- Custom Workflow activities
- Invoking TF exe directly
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不会签入输出。相反，我会将其移动到一个众所周知的位置，可能是文件共享。
I would not check an output in. Instead, I would move it to a well-known location, probably a file share.
我目前不这样做，但计划研究 NuGet 作为此场景的解决方案。 MSDN 有一些文章展示了如何将 NuGet 合并到您的项目中并托管您自己的 NuGet 包的私人图库。 MSDN 提供了一些构建示例，该示例可编译您的通用代码，然后将其打包并更新到您的私人 NuGet 库中。然后，在您的项目中，您将使用您想要使用的公共库的 NuGet 包。
MSDN 主要文章描述了这一点：
http://msdn.microsoft.com/en-us/magazine/hh781026.aspx
其他资源：
http://nuget.org/
http://nugetter.codeplex.com/
I don't do this currently but plan to investigate NuGet as a solution to this scenario. MSDN has some articles showing how to incorporate NuGet into your projects and host a private gallery of your own NuGet packages. MSDN has examples of a build that compiles your common code and then packages it and updates it into your private NuGet gallery. Then in your projects you would consume the NuGet package of the common library you wish to use.
Main MSDN article describing this:
http://msdn.microsoft.com/en-us/magazine/hh781026.aspx
Other resources:
http://nuget.org/
http://nugetter.codeplex.com/
查看 Ewald Hofman 的这篇文章，它更新某些文件并使用自定义活动签入它们。您可以使用相同的过程。但这涉及自定义构建过程模板并将自定义构建活动部署到所有构建代理。
但您可能还想研究一下免费的 AIT 依赖管理器，它可以从构建服务器下载一个构建的最新特定版本（可以根据构建结果或质量进行过滤）作为另一个构建（也在 Visual Studio 内）的参考。这比不断检查构建输出要灵活得多，并且允许您的开发分支始终获得最新（不稳定）版本，但您的发布分支始终获得最新的经过良好测试和批准的版本。
Have a look at this post from Ewald Hofman, it updates certain files and checks them in using a custom activity. You could use the same process. But this involves customizing the build process template and deploying custom build activities to all build agents.
But you might also want to investigate the free AIT Dependency Manager which can download the latest specific version (can filter on build outcome or quality) of one build from the buildserver as reference to another build (also inside Visual Studio). This is a lot more flexible than constantly checking in the build output and allows you to have your dev branch to always get the latest (unstable) version, but your release branch to always get the latest well tested and approved version.