Within the Project Object Model, the Application object has a method, FieldNameToFieldConstant(), that returns a PjField constant for use by the various SetField() and GetField() methods throughout the object model. More information on the SetField Method (and other associated methods) can be found here.

Unfortunately, when using the PSI, there’s no quick way to lookup the Guid for a field. This can be a problem, since the various CustomFieldsRow objects (Task, Resource, Assignment, and Project) do not include the name of the custom field, only the UID (for an example, look at the ProjectCustomFieldsRow entity in the Project 2007 SDK).

Retrieving custom field information in the PSI is accomplished by using the CustomFields web service. The code below is a class that implements a method to retrieve the Guid of a custom field using the field’s name and entity type. I had to chop the code up a lot because of space constraints, so I apologize for the excessive line breaks. This code assumes that you’ve set up a Web Reference to the CustomFields web service named WebSvcCustomFields.

In our previous article, we discussed Permission Levels for Project Web Access sites. We talked about how they were too liberal for most organizations and how to change them.

Unfortunately for us, the fact of the matter is that any changes you make to the default permission levels (in PWA or in a PWS) are not permanent, since the two Membership Synchronization processes overwrite them.

The PSI Methods for these two processes (QueueSynchronizeMembershipForWssSite and SynchronizeMembershipForPwaAppRootSite) can be found in the WssInterop service, which resides at http://ServerName/ProjectServerInstanceName/_vti_bin/psi/WssInterop.asmx. As previously discussed, both of them will delete and recreate the permission levels (or roles, depending which part of what document/interface/article/SDK you read) whenever triggered either by you or by Project Server.

At one time or another, almost everybody recieves an error while working in Project Server 2007’s Project Web Access. By default, SharePoint (and therefore Project Server 2007) are configured to present what are known as “custom” errors. These are an inherent part of ASP.NET that allow developers to create friendly error pages to report errors rather than the stock ones provided by the .NET Framework. These pages are generally simplistic and often leave out a great deal of information, such as stack traces. The reason for these pages is chiefly to spare the user the gory details of whatever unhandled exception just occurred. Unfortunately, not every error is or can be logged. This causes an obvious problem in Project Server deployments — especially when trying to resolve a transient error.

One of my clients has recently deployed a Sandbox of Project Server 2007 with MOSS 2007 (both RTM versions). During the course of this deployment they installed a number of the SharePoint Language Packs, in addition to creating a custom theme for Project Web Access. After deployment, they started having problems with incorrect rendering of the ASPX pages, along with some people recieving numerous authentication prompts (sometimes up to 17). In addition, for some people the page renders correctly on the initial load but manifests these problems if refreshed.

I believe the problem is one of two things: the permissions on the custom theme files, or some unforseen interaction with the language packs. The client is presently conducting further testing to confirm this theory. I have also suggested they fully patch both PS and MOSS from RTM to the Post-SP1 Hotfix Rollup.