Perforce API for the .Net CLR P4.Net

Overview

Introduction

P4.Net is an API for the Microsoft .Net Common Language Runtime (CLR). It can be used from any managed language including C#, VB.Net, and J#.

  • Support for Framework versions 1.1 and 2.0.
  • Results can be streamed as "pre-parsed", and are abstracted to "Recordsets" and "Records".
  • Direct manipulation of forms (p4 client, branch, user, etc.).
  • Connections are auto-managed (no need to set "ParseForms" or "Tagged" like other APIs).
  • P4PendingChangelist object makes submitting changes a snap.
    •

    License

    P4.Net is protected under this license, which is the MIT license.

    Support

    P4.Net is supported by me personally, in my spare time. If you have any issues you can contact me at p4shawn <at> gmail <dot> com. I use P4.Net at work extensively, so I'm motivated to fix any bugs. But I can't guarantee I'll be able to help everyone in a timely fashion, or even at all.

    P4.Net vs. P4COM

    P4COM can absolutely be used from managed languages w/o issues. So why would you want to use P4.Net? P4COM requires you to register the dll when deploying, but since P4.Net is entirely managed code, there is no need to register any dlls. You can literally use xcopy deployment (or p4 sync :-). Also, P4COM is constrained by some of the inherent limitations in COM. P4.Net uses inheritance, indexers and collection interfaces that all give it a cleaner, more .Net-like interface than P4COM (IMHO).

    Obtaining P4.Net

    P4.Net distributables can be downloaded here. It includes the binaries, help file (chm), and sample applications.

    Source code is maintained in the Perforce public depot: //guest/shawn_hladky/P4.Net

    Deploying P4.Net

    Choose the appropriate binaries. They are available strong-named or not, and for the 1.1 and 2.0 framework. Include the assemblies (p4dn.dll and p4api.dll) in the bin folder with your application, or install to the GAC.

    Architecture

    P4.Net is divided into two distinct components.

    p4dn: Written in C++ (with Managed Extensions), this component marshals all objects between the native Perforce C++ API and managed types. It generally follows the object model of the native Perforce API. It was ported from Jacob Gladish's implementation in the Perforce public depot.

    P4API: Written in C#, this component consumes p4dn, and abstracts the complexity of the native API into an easier to use interface. The object model is inspired from a combination P4Ruby, P4Python, P4COM, and ADO.

    Release Roadmap

    Past

    P4.Net began life in early 2004. I needed to build two Perforce automation tools to support some new processes. C# was the language of choice for these tools, but I've had a bad history with COM interop. So I looked for alternatives to P4COM, and I stumbled across Jacob Gladish's PerforceDotNet implementation in the Perforce public depot. I built these tools around PerforceDotNet, and ended up fixing a few bugs and adding functionality along the way.

    PerforceDotNet proved to be very robust, but its object model mirrored the native C++ API... which is not really friendly for simple day-to-day scripting. As a result, I didn't do much else with it. Instead, I was turned on to Python and P4Python. Flash-forward to early 2006, and I realized I needed to add some major enhancements to one of the PerforceDotNet-based applications. I dreaded having to work directly with PerforceDotNet's interface, and I seriously considered a full re-write in Python.

    But then I thought the Perforce community could really use a native .Net interface in the likes of P4Python. I realized I'd need a full layer on top of PerforceDotNet, that mimicked an object model more like P4Python. I also realized that PerforceDotNet would need some major changes to support the full API functionality. So I came up with the term P4.Net as an umbrella for the two components, and started submitting code.

    Present

    Of course, in typical software project fashion, I under-estimated the work involved. And even worse, I under-estimated the spare time I'd find to work on it. It's taken me about a year to deliver 0.9, the beta release. Although there are some known issues, I'm proud of the quality of this release... and I hope you find it to be more robust and functional than the typical open-source beta.

    Future

    1.0, general release, should be complete summer 2007. It will add support for print and raw form text, as well as fixing miscellaneous bugs.

    2.0 should be complete early 2008. It will focus on a major re-write of p4dn, and will only support the .Net framework 2.0. P4API will likely add overloaded methods to support generics for many inputs. And the one glaring bug, support for internationalized servers, will finally be fixed.

    Other ideas I have, but no plans on when they'll be implemented:

  • P4COM bridge. A wrapper class that mimics P4COM's object model, but uses P4.Net under the hood. This could be used as a drop-in replacement for .Net applications currently using P4COM... just update the reference and recompile.
  • Filelog object model. I've written a couple of scripts that try to interpret the output of p4 filelog... and I ended up with a bad headache at the end of the day. Tony Smith has come up with an object model to simplify this in P4Ruby. I'd like to do something similar in P4.Net.
  • Enhance P4MSBuildTasks. I'd like to take it from a sample application to a full-fledged product. This means it will need to support forms and have a lot more documentation.
  • Add a web application as a sample.
  • P4Python Bridge. Like the P4COM bride, this would allow Python scripts that used P4Python to run under IronPython using P4.Net, without changing the scripts.