Scrum Eventing Service woes (continued)

After receiving a response to my question on the Scrum for Team System Forum I investigated our problems somewhat further and noticed we were still running the Eventing Service from version 1.1, although I was convinced we did the upgrade to 1.2 as soon as it became available. Obviously I thought this was the very thing causing all this trouble.

As stated before in my previous post we recently moved the Eventing Service to its own Application Pool. We did this to make sure it wouldn’t crash our TFS server any more. When we tried to do the same thing with version 1.2 it no longer worked and Event Viewer showed this message: “GC handle cannot be shared among different application domains”. So we moved it back to the Application Pool belonging to TFS itself. The first couple of hours everything seemed just fine. The next morning however we had to recycle the Application Pool once again. I decided to stop the Eventing Service right there and then.

The next day I wrote a Windows Service which is currently running on our Continuous Integration Server and updates all Product Backlog Items once an hour by running the ScrumConsistencyChecker for every Scrum Project hosted on the TFS Server. It manages to do this in about 15 minutes for the 20 projects we currently host and this without any impact on the TFS Server. Which is, by the way, running just fine without the Eventing Service and hasn’t required any recycling since.