change from Project Server on premises installs is that event handlers are no
longer DLLs that you register on the app server. For project online, event
receivers must call a public facing web service to process requests. We will
look at the challenges we faced implementing this approach for a Project
little documentation on Event Receivers and how to set them up. All of the
information on Project Server events (in terms of the method names to override
and the parameter types expected) were gathered by looking through the
Microsoft.ProjectServer.Client dll and finding the appropriate objects. If you
recall, an event handler needs to override the targeted event method and accept
discovered was we needed a reference to Microsoft.ProjectServer.Client in our
web service in order to access the parent “ProjectEventReceiver” class and
override the “OnCreatingRemote” event.
eventually classified as a typical challenge of developing for a new product
which is partially true, but a little guidance would have saved some time.
right. There is no administration UI in Project Online or SharePoint Online
Administration by which a user can add/remove event receivers. When we
discovered this we were surprised to say the least. We thought that maybe event
receivers were not yet working in Project Online, but no documentation seemed
to back up our suspicion.
prompted us to head back into the Microsoft.ProjectServer.Client assembly to
figure out how events are actually registered. After some digging, we did find an
object “EventHandlerCreationInformation” which seemed to be the object we were
looking for. This is how you register an event in Project Online:
time we need to manage event receivers in the cloud we have to run a piece of
code, which meant we needed to build a registration UI. So we created a simple
windows application which can read/manage events on an online tenant. Consider this as well: almost 90% of the time a call to register/unregister an event fails with a
timeout error. BUT, when we read the event status, the event is actually
registered! It seems the action to register/unregister is completed in the cloud, the call just never returns.
receivers are extremely slow. It is common sense to realize that calling an
external web service when an event occurs (such as project creation) will slow
down the process a bit, but the event receiver times out making the process
We ran a
few tests creating projects with our event receiver attached. Our web service
logged when it was executed (when the request started and when it finished) to
determine if the delay was caused by our code or some other part of the process.
It wasn’t our code.
The web service consistently completed the request between 1-3 seconds, but
Project online would keep spinning. The system was unusable, and frequently
project creation would just stop because it was waiting for the event to
If an event
receiver times out, the action does not complete. If the server on which the
web service is hosted is not available, the action does not complete. So in a
case of a mysterious timeout (mentioned in the previous section) or a server
failure, projects will not be created. A better alternative would be to allow
the project creation process to continue regardless of the result of an event
receiver. The risk of installing such a feature is too high for any admin to take.
= Not a Solution
lack of documentation and a registration UI can be tackled with development
knowledge and code, the slow performance and error handling make Project Online
event receivers an unusable technology. If you are contemplating a solution
design that requires an event receiver save yourself the time and money by coming up with another idea. I only hope that more patches and releases to the Project Online environment will fix this behaviour in the future.