我们使用 TFS 作为版本控制。目前,项目管理是通过我们当地的 PMS 应用程序完成的。我们有一个要求,比如当团队成员签入项目时,显示用于输入任务详细信息的自定义对话框并更新我们的本地 pms 数据库。我想显示一个自定义对话框,该对话框和/或在调用签入命令之后。还要确保只有通过这个自定义对话框成功提交了任务详情,我们才能签入项目。
2 回答
创建您自己的签到政策
您可以通过签到政策来做到这一点。查看我关于在签到时与用户交互的博文。基本技巧是引发用户可以单击的签入警告,在单击事件上,您可以向用户显示 UI 并使用标准 Windows 窗体功能与您的系统进行交互。
最基本的示例代码可以在这个 StackOverflow 问题中找到。
我的多分支策略使用此技巧来要求用户确认用户是否真的想要同时将代码签入多个分支,而无需使用绕过策略验证复选框。
关于安装 Checkin 策略的说明
将 Team 项目配置为使用签入策略后,如果签入时计算机上未安装该策略,Visual Studio 会报错。没有简单的方法来分发签入策略以确保每个用户都将其安装在他们的计算机上,或者会自动从 TFS 安装它。
在您的签入策略中,您可以通过IPolicyDefinition.InstallationInstructions
. 该包可以是一个.msi
.a.vsix
或只是一个带有脚本的 zip 文件,用于复制程序集并添加所需的注册表项。Visual Studio 不关心您选择的方法。如果您的公司拥有自己的 Visual Studio 库,它也可以指向那里的下载位置。
如果您选择一个,.msi
您可以通过您的组织中可能可用的现有配置工具来分发它们。
未安装策略的客户端将在签入时自动触发警告,只能通过选中“绕过签入策略”复选框来解除该警告。可以撤销该权限,要求所有用户正确设置他们的机器。
还有另一种分发签入策略的方法,即通过 Visual Studio Power 工具。通过签入特定文件夹中源代码管理中的策略并告诉 Power Tools 下载自定义二进制文件(工作项控件和签入策略),它们将自动安装。由于默认情况下未安装这些工具,默认情况下未配置它们需要大约相同数量的工作才能使此方案适合您。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using Microsoft.TeamFoundation.VersionControl.Client;
namespace TFSPMSIntegration
{
[Serializable]
public class CheckForPMSDetails : PolicyBase
{
public bool pmsDetailsConfirmed=false;
private static frmPmsDetails _frm = null;
public override string Description
{
get { return "Remind users to add PMS details to their checkins"; }
}
// This is a string that is stored with the policy definition on the source
// control server. If a user does not have our policy plugin installed, this string
// will be displayed. We can use this as an opportunity to explain to the user
// how they might go about installing our policy plugin.
public override string InstallationInstructions
{
get { return "To install this policy, follow the instructions in CheckForPMSDetails.cs."; }
}
// This string is the type of our policy. It will be displayed to the user in a list
// of all installed policy types when they are creating a new policy.
public override string Type
{
get { return "Check for PMS Details"; }
}
// This string is a description of the type of our policy. It will be displayed to the
// user when they select our policy type in the list of policies installed on the system
// as mentioned above.
public override string TypeDescription
{
get { return "This policy will prompt the user to decide whether or not they should be allowed to check in."; }
}
// This method is invoked by the policy framework when the user creates a new checkin
// policy or edits an existing checkin policy. We can use this as an opportunity to
// display UI specific to this policy type allowing the user to change the parameters
// of the policy.
public override bool Edit(IPolicyEditArgs args)
{
// no configuration to save
return true;
}
// This method performs the actual evaluation. It is called by the policy framework at various points in time
// when policy should be evaluated. In this example, we invoke this method ourselves when various asyc
// events occur that may have invalidated the current list of failures.
public override PolicyFailure[] Evaluate()
{
if (!pmsDetailsConfirmed)
{
return new PolicyFailure[] {
new PolicyFailure("Please provide PMS Details about your checkin", this),
};
}
else
{
//frmPmsDetails frm = Application.OpenForms["frmPmsDetails"] as frmPmsDetails;
if(_frm!=null)
PendingCheckin.PendingChanges.Comment = _frm.txtDescription.Text;
return new PolicyFailure[0];
}
}
// This method is called if the user double-clicks on a policy failure in the UI.
// We can handle this as we please, potentially prompting the user to perform
// some activity that would eliminate the policy failure.
public override void Activate(PolicyFailure failure)
{
//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.
//Singleton approach needed , otherwise each time we click on policy message error, it will open multiple forms(UI)
if (_frm == null)
_frm = new frmPmsDetails(this);
else
_frm.CheckForPMSDetails = this;
_frm.WindowState = FormWindowState.Minimized;
_frm.TopMost = true;
_frm.Show();
_frm.ClearAll();
_frm.WindowState = FormWindowState.Normal;
_frm.BringToFront();
}
public void fn_Evaluate()
{
pmsDetailsConfirmed = true;
base.OnPolicyStateChanged(Evaluate());
}
// This method is called if the user presses F1 when a policy failure is active in the UI.
// We can handle this as we please, displaying help in whatever format is appropriate.
// For this example, we'll just pop up a dialog.
public override void DisplayHelp(PolicyFailure failure)
{
MessageBox.Show("This policy helps you to remember to add PMS details to your checkins.", "Prompt Policy Help");
}
}
}
自定义签到策略部署
首先使用您的业务逻辑为自定义签入策略创建类库
使用易于安装的 VSIX 包将您的签入策略部署到客户。
您想要为 VS 2010、VS 2012 和 VS 2013 构建自定义签入策略,那么您需要一台同时安装所有这三个 Visual Studio 版本的机器,并且您需要 Visual每个都安装了 Studio SDK。VSIX 项目模板仅在成功安装 Visual Studio SDK 后可用。
在 Visual Studio 2012 版本中使用 VSIX 包创建签入策略的步骤
1.在visual studio 2012版本中新建项目。
2.选择可扩展性项目模板,然后选择 VSIX 项目模板。
- 在 VSIX 项目中添加对自定义签入策略项目的引用
您应该在项目中添加一些项目,例如图标位图和 License.txt,但其中只有一项是强制性的:“policies.pkgdef”
- 您只需添加一个文本文件,并将其命名为 policies.pkgdef。名称可以是任何名称,但扩展名应为“pkgdef”。
- 编辑 policy.pkgdef 使其看起来像这样:
[$RootKey$\TeamFoundation\SourceControl\Checkin 策略] "TFSPMSIntegration"="$PackageFolder$\TFSPMSIntegration.dll"
第 1 部分:这是您为策略包选择的名称,它将是注册表中键的名称 第 2 部分:这是在项目属性应用程序/程序集名称字段中定义的程序集名称。
- 最后,您必须设置 vsixmanifest 文件,该文件名为 source.extension.vsixmanifest。
选择资产选项卡并使用“添加新资产”窗口添加“policies.pkgdef”文件
您必须构建解决方案,并通过双击安装 VSIX。请注意,它首先在您重新启动 Visual Studio 时生效。
*为了禁用和卸载软件包,请转到 Visual Studio 工具菜单并选择“扩展和更新”
选择扩展并执行适当的操作