自定义签入策略是否必须部署在服务器上?

发布于 2024-08-01 18:08:21 字数 618 浏览 3 评论 0原文

我问这个问题是因为我没有在任何地方看到它的记录。 我们使用 Team Foundation Server 2008 和 Team Explorer 2005 的组合。

是否可以部署适用于此类环境的自定义签入策略?

显然,自定义签入策略包含一些必须在客户端运行的代码(以便显示帮助等)。 因此它应该使用 Team Explorer 2005 附带的 Microsoft.TeamFoundation.VersionControl.Client 程序集。

但是,我的感觉告诉我,为了有效,应该在服务器本身上强制执行签入策略(例如,以支持从命令行或使用原始 Web 服务 API 签入更改)。 因此,它必须针对 Team Foundation Server 2008 附带的 Microsoft.TeamFoundation.VersionControl.Client 运行。

因此,是否可以构建采用最新版本 Microsoft.TeamFoundation 的单个自定义签入策略.VersionControl.Client 程序集(客户端为 2005,服务器为 2008)?

或者我是否必须构建两种自定义签入策略,一种用于客户端,一种用于服务器? 那行得通吗?

或者自定义签入策略是否只存在于客户端?

I'm asking this question because I haven't seen it documented anywhere.
We are using a combination of Team Foundation Server 2008 and Team Explorer 2005.

Is it possible to deploy a custom check-in policy that works in such an environment ?

Obviously, the custom check-in policy contains some code that must run on the client-side (in order to display help, etc.). So it should use the Microsoft.TeamFoundation.VersionControl.Client assembly that comes with Team Explorer 2005.

But, my sense tells me that, in order to be effective, a check-in policy should be enforced on the server itself (for example, to support checking-in changes from the command-line or using the raw Web Services API). So, there, it would have to run against the Microsoft.TeamFoundation.VersionControl.Client that comes with Team Foundation Server 2008.

So, is it possible to build a single custom check-in policy that takes the most recent version the Microsoft.TeamFoundation.VersionControl.Client assembly (2005 on the client and 2008 on the server)?

Or do I have to build two custom check-in policies, one for the client and one for the server ? Would that even work ?

Or do custom check-in policies only ever exist on the client side ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

记忆消瘦 2024-08-08 18:08:21

自定义签入策略仅存在于客户端,并且仅在客户端进行评估。 如果客户端计算机上缺少 DLL,TFS 将发出警告,但会提供一个对话框,允许用户覆盖错误并无论如何进行签入。

The custom check-in policies only exist at client-side, and will only be evaluated client-side. If the DLL is missing on the client computer, TFS will complain, but provide a dialog that allows the user to override the error and check in anyways.

笑梦风尘 2024-08-08 18:08:21

不,这不是必需的。 然而,它使事情变得容易得多。 使用最新的Power Tools,您可以将签入策略存储在源中控制并“免费”部署它们。

带有屏幕截图的演练位于 Brian 的博客

....自从我们推出这些功能以来,客户就一直在寻求一种将此类自定义组件分发给客户的方法,而不必手动安装它们。 好吧,我很高兴地说,这个新版本的 Power Tools 就是这样做的!

由于下载自定义组件并在客户端上运行它们可能很危险,因此需要相当小心以及启用它所需的一些配置。 团队项目的自定义组件将签入名为 $//TeamProjectConfiguration 的新“特殊”文件夹中。 让我向您展示一些屏幕截图,这将帮助您了解其工作原理......

No, it's not required. However, it makes things much easier. Using the latest Power Tools you can store check-in policies in source control and have them deployed for "free."

A walkthru with screenshots is on Brian's blog:

....Since the day we introduced those features, customers have asked for a way to distribute custom components like these to clients rather than having to manually install them. Well, I'm happy to say that this new release of the Power Tools does just that!

Due to the fact that downloading custom components and running them on clients can be dangerous, there's a fair amount of care taken and some configuration necessary to enable it. Custom components for a Team Project are checked in to a new "special" folder called $//TeamProjectConfiguration. Let me show you a few screen shots and that will help walk you through how this works....

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文