Project Server Curios: The QueueDeleteArchivedProject method
I encountered a rather interesting bug in the Project Server API a few days ago as I tried to create a utility to clean-up the Archive database of a few thousand old project versions. The proper way to do this is to call the
Archive.QueueDeleteArchivedProject method. Unfortunately, the method has a few problems.
- An unknown parameter, archiveID. There is no such parameter anywhere in the Archive web service API.
- Passing a Project GUID to the projectUID didn't delete any archived versions.
- Passing ac Project GUID to the archiveID DID delete the versions.
After some spellunking with Reflector, I found out that:
- The archiveID parameter actually refers to the PROJ_VERSION_UID column of the ArchivedProjects.Project Datatable.
- The parameters were actually in the wrong order. Somewhere deep inside the web service's implementation, in the Microsoft.Office.Project.Server.BusinessLayer.Admin.QueueDeleteArchiveProjectInternal method, a ProjectDeleteParamsMessage object was constructed with the parameters in the wrong order. The projectUID parameter was passed to the projectVersionUID parameter and vice-versa.
My spellunking adventure left me wondering a few things:
- If this method doesn't work as documented, how does the Project Server UI delete old project versions?
One possible answer is that the UI doesn't use this version. In many cases, Project Server uses the almost-totally-undocumented Admin service. It seems that this is just such a case.
- How come no-one noticed this before? Well, at least one other developer asked about this issue a year ago but received no valid answer.
- What do I do now? I can call the function with reversed parameters, but what happens when MS fixes the bugs?
How will they fix it?
Will they reverse the parameters? That would break any code that works with the current version of the method.
Will the rename the parameters? That would be confusing, as other methods, like QueueRestoreProject have the same parameters in the current order. Additionally, preserving the current order wouldn't fix the bug in the internals of the Archive web service.
- Where do I report the bug? There is no Project Server Connect site, at least none that is listed in the Connect Site. Searching for Project Server reveals that there is indeed a Project Server site but when I try to access it I get a "Page not Found" error.
UPDATE:
I just found out that the Archive.ReadArchivedProjectsList is also affected and returns a project's UID in the PROJ_VERSION_UID column and the version UID in the PROJ_UID column. It would seem that the confusion between Project and Project Version UIDs goes all the way to the Archive database. The MSP_Projects uses a PROJ_UID column as key that holds the Project Version UID instead of a project's actual UID.
This means that any code that wants to work with a specific project's versions has to search in the PROJ_VERSION_UID column for the project's UID.