P4.Net Sample Applications

About the samples

All of the sample applications are written in Visual Studio 2005. If you don't have VS2005, you can still build them with MSBuild and the .Net 2.0 SDK.

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 readily 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.

JobLabeler requires some administrative setup to run. See the readme file for details.

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 imagine 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.exe directly? The key is the rich output. The P4RunCommand task outputs an itemgroup representing each P4Record output. All the key/value pairs are represented as Item metadata. As an example, the output from p4 files would be an itemgroup similar to the following:

<ItemGroup>
  <P4Output Include="P4Output-files-00000000">
    <change>5427</change>
    <rev>1</rev>
    <type>text</type>
    <depotFile>//depot/file1.txt</depotFile>
    <action>add</action>
    <time>1146612676</time>
  </P4Output>
  <P4Output Include="P4Output-files-00000001">
    <change>5798</change>
    <rev>2</rev>
    <type>text</type>
    <depotFile>//depot/file2.txt</depotFile>
    <action>edit</action>
    <time>1166501810</time>
  </P4Output>
</ItemGroup>

Using batching and transformations, you can use this output later in the script. For example, you can print a line 'file#revision' for each record output by batching:

<Message Text="%(P4Output.depotFile)#%(P4Output.rev)" />

You can also use transformations to feed output of one Perforce command into the input of another. Check out the sample "WorkingOffline.proj". It is well-commented, and provides a number of techniques you can use.