Partager via


CheckInParameters.QueueBuildForGatedCheckIn Property

Gets or sets a flag describing whether to queue the build for a gated check-in.

Namespace:  Microsoft.TeamFoundation.VersionControl.Client
Assembly:  Microsoft.TeamFoundation.VersionControl.Client (in Microsoft.TeamFoundation.VersionControl.Client.dll)

Syntax

'Déclaration
Public Property QueueBuildForGatedCheckIn As Boolean
    Get
    Set
public bool QueueBuildForGatedCheckIn { get; set; }
public:
property bool QueueBuildForGatedCheckIn {
    bool get ();
    void set (bool value);
}
member QueueBuildForGatedCheckIn : bool with get, set
function get QueueBuildForGatedCheckIn () : boolean
function set QueueBuildForGatedCheckIn (value : boolean)

Property Value

Type: System.Boolean
True to queue build for gated check-in; otherwise, false.

Remarks

If one or more of the items being checked in affects a gated build definition, the check-in will be rejected because it must go through the gated check-in system. The server will create a shelveset of the changes submitted for check-in and throw a GatedCheckinException to the client containing the names of the affected build definitions, the name of the created shelveset, and a check-in ticket string (a cookie). The client must call IBuildServer.QueueBuild with an IBuildRequest containing the shelveset name, the checkin ticket string, and a reason of BuildReason.CheckInShelveset. The build can be queued against any of the affected definitions.

However, some of this work can be automated by the server if the QueueBuildForGatedCheckIn flag is true, and the items being checked in affect exactly one gated build definition. In this case the call to checkin will still fail with a GatedCheckInException, but the changes will be queued for validation automatically by the server. If the build succeeds, the changes will be checked in by the build service.

.NET Framework Security

See Also

Reference

CheckInParameters Class

Microsoft.TeamFoundation.VersionControl.Client Namespace