| Perforce API for the .Net CLR |  |
| Perforce API for the .Net CLR | |
Perforce servers running in "unicode" or "internationalized" are untested. At a minimum, metadata stored with non- ASCII characters will get mangled, and P4.Net may not work at all.
In the current implementation, all string conversions between managed and native code assume the native code is ANSI encoded. I will need to build a string conversion method in p4dn that will know when we are connected to an internationalized server, and translate from the appropriate encoding. It will take a little testing to determine whether to use Perforce's translation API or .Net's (or some combination of the two). P4Python and P4COM shows how to use the undocumented "translate" method in the C++ API.Direct manipulation of the form text is not supported. That is, there is no way get the raw text of a from command or to save a form with the raw form. Instead, you must use the P4Form object.
In P4.Net, there’s no straight-forward way to submit the default pending changelist. This is by design. If the client workspace has opened files in the default changelist before any P4.Net automation runs, those files will "come along for the ride" when you submit the default changelist. If the user has a JobView set, all jobs in that JobView will automatically be fixed when you submit that default changelist. Both of those behaviors are almost never desired, and I’ve found many scripts that have those bugs.
You can not change the P4Port setting after a P4Connection has been connected. This is true even after a Disconnect(). Instead, create a new P4Connection object.
There is currently no way to obtain an in-memory stream of file contents using the 'print' command. In other APIs, if multiple files are output using 'print', the contents of the file are concatanated into one in-memory variable. I have an idea that would correct this behavior, but it is more complex to consume. So I've punted on the idea for now, and it is unsupported.
The parsed output for the of the filelog command is awkward. In the native C++ api, the integration metadata is a sparse 2 dimensional array. The parsing logic in P4.Net does not account for this, so you end up with an ArrayFieldDictionary with keys like 'fromFile1,'. So, I could fix this, and come up with some sort of TwoDimArrayFieldDictionary. However, the trying to make sense of the filelog output using the 2-d arrays will almost certainly give you a headache. Instead, I want to research Tony Smith's implementation in P4Ruby. He has created an object model that represents the filelog metadata in an easy-to-use interface.