The haunted house of callouts

One of the integrations implemented for our CRM environment includes a feature that writes entries to a dedicated Error Log entity. This can be a convenient way to provide the end users access to error notifications, when the process itself is asynchronous and does not provide a way to prompt the user.

During the development project of this integration, frequent updates were made to this callout dll file and I received new versions to be deployed from the developers almost on a daily basis. After one particular update, we were surprised to notice that the callout was still writing an error messge into the custom entity, which was not supposed to be there. In fact, the whole message string no longer existed in the dll file. Where did his ghost messages appear from?

It turned out that merely stopping and starting IIS does not guarantee that the previous version of a callout would not remain in the cache. If there are any workflows associated with the entities that the callout references, these can keep the old version of the dll loaded up in memory, thus creating the “haunting” effect described.

As a lesson learned, whenever I need to update a callout dll file, I now go through the following steps:

• Stop the CRM Workflow Service (net stop mscrmworkflowservice)
• Stop IIS (iisreset /stop)
• Replace the callout dll
• Start IIS (iisreset /start)
• Start the CRM Workflow Service (net start mscrmworkflowservice)