P4.Net Sample Applications

Job Labeler

Job labeler is a Windows service that polls the Peforce server for new job fixes, and creates a label representing the files fixed by a job.

Motivation: Many shops use jobs to organize a collection of changes. For example, if you have Perforce integrated with a defect tracking system, you will have a job representing a defect, and there may be several changes fixed by that job. A frequent question that comes up is, "What files were modified to fix this defect?" Since the JobLabeler sample application creates a label representing the files fixed by a job, this question is readilly answered with "p4 files @={joblabel}".

Techniques: Even if you don't use jobs in this manner (or jobs at all), there are a number of techniques that may be used in your applications.

Using P4.Net from a Windows service

Polling the Perforce server for change.

Reading/Writing counters to maintain state.

Using parsed and unparsed output of several commands.

Fetching/Setting p4 settings from an app.config file.

Recordset Viewer

Recordset Viewer is a Windows GUI application that helps the user visualize the Recordset output from the commands they run.

Motivation: When you're using P4.Net (or other P4 APIs), it can be difficult to sort through the vast information returned from Perforce. The RecordsetViewer graphically displays all the key/value pairs, as well as messages, warnings, and errors.

Techniques: A few techniques are demonstrated:

Validating a variety of Perforce connection settings.

A connection dialog.

This is the only sample in VB.Net.

Iterating P4RecordSet objects.

MSBuild Custom Tasks

P4MSBuildTasks is a .Net assembly providing custom tasks for MSBuild.

Motivation: Integrating MSBuild with Perforce is something a lot of shops will want to do. I immagine there will be a number of people that use these tasks, and don't even care about the internals of P4.Net.

Usage: P4MSBuildTasks works quite a bit differently than the traditional source control integration tasks (for MSBuild, NAnt, or Ant). The traditional approach is to have individual tasks to perform a specific action. For example, you might have tasks like P4Sync, P4Edit, P4Label, etc.

In P4MSBuildTasks, there's one main task that executes any Perforce command. So how's that any better than just executing p4 from the command-line? The key is the rich output. The P4RunCommand task outputs an itemgroup represnting each P4Record output. All the key/value pairs are represented as Item metadata.

Check out the sample "WorkingOffline.proj". It is well-commented, and provides a number of techniques you can use.