TFS客户端侧挂钩

Question

我们使用TFS作为版本控制.目前,项目管理是通过我们当地的PMS应用程序完成的.我们有一个要求,例如当团队成员检查项目时,显示用于输入任务详细信息的自定义对话框并更新我们的本地pms数据库.我想显示一个自定义对话框,和/或调用签入命令后.同时确保只通过此自定义对话框成功提交任务详细信息,我们可以签入项目.

Answer 1

创建自己的签入政策

您可以通过签到策略执行此操作.查看我在博客文章中关于在办理登机手续时与用户互动的信息.基本技巧是提出用户可以单击的签入警告,在单击事件上,您可以向用户显示UI并使用标准Windows窗体功能与您的系统进行交互.

最简单的例子代码可以在这个StackOverflow的问题中找到.

我的多分支策略使用此技巧要求用户确认用户是否确实要同时将代码签入多个分支,而不必使用绕过策略验证复选框.

有关安装Checkin政策的说明

配置Team项目以使用签入策略后,Visual Studio将在签入时未在计算机上安装策略时进行投诉.没有简单的方法来分发签入策略,以确保每个用户都在其计算机上安装它,或者自动从TFS安装它.

在您的签入策略中,您可以通过提供策略包位置的URI IPolicyDefinition.InstallationInstructions.该包可以是a .msi,a .vsix或只是一个zip文件,其中包含用于复制程序集和添加所需注册表项的脚本.Visual Studio不关心您选择的方法.如果您的公司拥有自己的Visual Studio库,它也可以指向那里的下载位置.

如果您选择了一个.msi,则可以通过组织中可用的现有配置工具进行分发.

未安装策略的客户端将自动触发签入时的警告,该警告只能通过选中"绕过签入策略"复选框来解除.该权限可以被撤销,要求所有用户正确设置他们的机器.

还有一种方法可以通过Visual Studio Power工具分发签入策略.通过签入特定文件夹中的源代码管理中的策略并告诉Power Tools下载自定义二进制文件(工作项控件和签入策略),它们将自动安装.由于默认情况下未安装这些工具,因此默认情况下未配置这些工具,因此需要大约相同的工作量才能使此方案适合您.

Answer 2

 using System;\n    using System.Collections.Generic;\n    using System.Linq;\n    using System.Text;\n    using System.Threading.Tasks;\n    using System.Windows.Forms;\n    using Microsoft.TeamFoundation.VersionControl.Client;\n    namespace TFSPMSIntegration\n    {\n        [Serializable]\n        public class CheckForPMSDetails : PolicyBase\n        {\n            public bool pmsDetailsConfirmed=false;\n            private static frmPmsDetails _frm = null;\n            public override string Description\n            {\n                get { return "Remind users to add PMS details to their checkins"; }\n            }\n    \n            // This is a string that is stored with the policy definition on the source\n            // control server.  If a user does not have our policy plugin installed, this string\n            // will be displayed.  We can use this as an opportunity to explain to the user\n            // how they might go about installing our policy plugin.\n            public override string InstallationInstructions\n            {\n                get { return "To install this policy, follow the instructions in CheckForPMSDetails.cs."; }\n            }\n    \n            // This string is the type of our policy.  It will be displayed to the user in a list\n            // of all installed policy types when they are creating a new policy.\n            public override string Type\n            {\n                get { return "Check for PMS Details"; }\n            }\n    \n            // This string is a description of the type of our policy.  It will be displayed to the\n            // user when they select our policy type in the list of policies installed on the system\n            // as mentioned above.\n            public override string TypeDescription\n            {\n                get { return "This policy will prompt the user to decide whether or not they should be allowed to check in."; }\n            }\n    \n            // This method is invoked by the policy framework when the user creates a new checkin\n            // policy or edits an existing checkin policy.  We can use this as an opportunity to\n            // display UI specific to this policy type allowing the user to change the parameters\n            // of the policy.\n            public override bool Edit(IPolicyEditArgs args)\n            {\n                // no configuration to save\n                return true;\n            }\n    \n            // This method performs the actual evaluation.  It is called by the policy framework at various points in time\n            // when policy should be evaluated.  In this example, we invoke this method ourselves when various asyc\n            // events occur that may have invalidated the current list of failures.\n            public override PolicyFailure[] Evaluate()\n            {\n                \n    \n                if (!pmsDetailsConfirmed)\n                {\n                    return new PolicyFailure[] {\n                        new PolicyFailure("Please provide PMS Details about your checkin", this),\n                    };\n                }\n                else\n                {\n                   //frmPmsDetails frm = Application.OpenForms["frmPmsDetails"] as frmPmsDetails;\n                    if(_frm!=null)\n                    PendingCheckin.PendingChanges.Comment = _frm.txtDescription.Text;\n                    return new PolicyFailure[0];\n                }\n            }\n    \n            // This method is called if the user double-clicks on a policy failure in the UI.\n            // We can handle this as we please, potentially prompting the user to perform\n            // some activity that would eliminate the policy failure.\n            public override void Activate(PolicyFailure failure)\n            {\n                //The Singleton design pattern is used for maitntain only one instance of Form class(UI).But everytime we have passing new value to the custom policy class.\n                //Singleton approach needed , otherwise each time we click on policy message error, it will open multiple forms(UI)\n                if (_frm == null)\n                    _frm = new frmPmsDetails(this);\n                else\n                    _frm.CheckForPMSDetails = this;\n              \n                _frm.WindowState = FormWindowState.Minimized;\n                _frm.TopMost = true;\n                _frm.Show();\n               _frm.ClearAll();\n                _frm.WindowState = FormWindowState.Normal;\n                _frm.BringToFront();\n                \n            }\n            public void fn_Evaluate()\n            {\n    \n                pmsDetailsConfirmed = true;\n                base.OnPolicyStateChanged(Evaluate());\n               \n    \n            }\n    \n            // This method is called if the user presses F1 when a policy failure is active in the UI.\n            // We can handle this as we please, displaying help in whatever format is appropriate.\n            // For this example, we\'ll just pop up a dialog.\n            public override void DisplayHelp(PolicyFailure failure)\n            {\n                MessageBox.Show("This policy helps you to remember to add PMS details to your checkins.", "Prompt Policy Help");\n            }\n            \n        }\n    }\n

\n\n

自定义签入策略部署

\n

\n

• 首先使用您的业务逻辑创建自定义签入策略的类库\n

  \n
\n

• 使用易于安装的 VSIX 包向客户部署签入策略。\n

  \n
\n

• 您想要为 VS 2010、VS 2012\n和 VS 2013 构建自定义签入策略，那么您\xe2\x80\x99 将需要一台同时安装所有这三个版本的计算机\nVisual Studio 版本，并且您\xe2\x80\x99 需要为每一个安装\nVisual Studio SDK。VSIX 项目\n模板仅在成功安装 Visual\nStudio SDK 后可用。

  \n
\n

\n

在 Visual Studio 2012 版本中使用 VSIX 包创建签入策略的步骤

\n

\n

1. 在 Visual Studio 2012 版本中创建新项目。

   \n
\n

2. 选择可扩展性项目模板，然后选择 VSIX 项目模板。\n

   \n
\n

3. 在 VSIX 项目中添加对自定义签入策略项目的引用\n

   \n
\n

4. 您应该向项目添加一些项目，例如图标位图和 License.txt，但只有其中之一是必需的 \xe2\x80\x9cpolicies.pkgdef\xe2\x80\x9d

   \n
\n

\n

\n

\n

5. 您只需添加一个文本文件，并将其命名为policies.pkgdef。名称可以是任何名称，但扩展名应为 \xe2\x80\x9cpkgdef\xe2\x80\x9d。

   \n
\n

6. 编辑policies.pkgdef，使其看起来像这样：

   \n
\n

\n

\n

[$RootKey$\\TeamFoundation\\SourceControl\\签入策略]\n"TFSPMSIntegration"="$PackageFolder$\\TFSPMSIntegration.dll"

\n

\n

\n

第 1 部分：这是您选择为策略包指定的名称，这将是注册表中密钥的名称

\n

第 2 部分：这是在项目属性的“应用程序/程序集名称”字段中定义的程序集名称。

\n

\n

7. 最后，您必须设置 vsixmanifest 文件，即名为 source.extension.vsixmanifest 的文件。

   \n
\n

8. 选择“资产”选项卡并使用 \xe2\x80\x9c 添加新资产\xe2\x80\x9d 窗口\n 添加 \xe2\x80\x9c 策略.pkgdef\xe2\x80\x9d 文件

   \n
\n

9. 您必须构建解决方案，并通过双击它来安装 VSIX。请注意，它首先在您重新启动 Visual Studio 时生效。

   \n
\n

\n

*为了禁用和卸载该包，请转到 Visual Studio 工具菜单并选择 \xe2\x80\x9cExtension 和 Updates\xe2\x80\x9c\n

\n

选择扩展并执行适当的操作\n

\n