There are a number of config options for the TFS Event Handler Prototype . I will describe all of them in depth here. The first step is to set the Windows Communication Foundation service options, which really only requires you to change one value.
<system.serviceModel> <services> <service name="RDdotNet.TeamFoundation.NotificationService"> <endpoint address="http://[LocalMacheneName]:8677" binding="basicHttpBinding"
bindingConfiguration="" contract="RDdotNet.TeamFoundation.INotificationService" /> </service> </services> </system.serviceModel>
The important one is the [LocalMacheneName] variable, which should be set to the local machine name, or the domain name that points to your computer if you have a crazy proxy.
The next step is to set the real options for this software. This starts with the <RDdotNet .TeamFoundation> options and requires you to set a number of things.
<BaseAddress url="http://[LocalMacheneName]:3624/" />
Again you need to set the machine name, but make sure that the port is different.
<TeamServers> <TeamServer name="[TFS Server Name]"
url="http://[TFS Server Name]:8080/"
subscriber="[Subscriber AD Account]"
mailAddressFrom="[From Email Address]"
mailFromName="[Form name]"
mailServer="[email relay server]"
logEvents="True"
testMode="True"
testEmail="[email to send testes to]"
eventLogPath="C:tempTFSEventHandler"> </TeamServer> </TeamServers>
In the Team Servers section you need to list all of the team servers that you are going to be handling events for. The system will automatically add the event subscriptions for all team servers added here, but I have only tested with two and I now always run the service on the TFS server.
TeamServer Options
| Name | Type | Description |
| name | System.String | This should be a friendly name for the team foundation server |
| url | System.Uri | The URI for the TFS server you wish to connect to including protocol and port. |
| mailFromAddress | System.String | The address from which you want all emails sent by the system to say that they are sent. |
| mailFromName | System.String | The display name of the from email address |
| mailServer | System.String | The mail server that you have permission for to send emails |
| logEvents | System.Boolean | A true or false value that enables logging of all events within that system. Excellent for debugging... |
| testMode | System.Boolean | When in test mode all emails sent by the system will only be sent to email address defined by testEmail. Set to false for production. |
| testEmail | System.String | The email address that, when testMode is enabled will receive all emails sent from the system. |
| eventLogPath | System.String | the location that the event logs will be written to. All events received get assigned a System.Guid and all logs pertaining to that event get saved in the corresponding folder. |
| subscriber | System.String | The AD account name of the account that is writing the events. Set to the name of your TFSSetup or TFSService accounts. |
Now you are ready to set the event handlers. These are defined within the “Events” section:
<Events>
<Event eventType=“WorkItemChangedEvent”>
<Handlers>
<Handler type="RDdotNet .TeamFoundation.WorkItemTracking.AssignedToHandler"
assemblyFileName="RDdotNet .TeamFoundation.WorkItemTracking.AssignedTo.dll"
assemblyFileLocation="~EventHandlersWorkItemTracking">
</Handler>
</Handlers>
</Event>
</Events>
As you can see you are theoretically allows to us any events. Please keep in mind that only the WorkItemChangedEvent and the CheckInEvent have been tested. When you add the “Event” tag with the corresponding eventType (which is an enumerator) this tells the system which specific events to subscribe to.
You can then add handlers to an event. These handlers are fired whenever these events are received.
| Name | Type | Description |
| eventType | RDdotNet.TeamFoundation.EventTypes | Enumerator that defines the list of possible events. |
| type | System.Type | This must be a valid type in the assembly listed in assemblyFileName |
| assemblyFileName | System.String | This must be a valid assembly found in the assemblyFileLocation |
| assemblyFileLocation | System.String | A location within the servers file system that holds this assembly. ~ denotes the applications root. |
If you are using friendly server names or TeamPlain the you can change the TFS server links to be TeamPlain ones using the UrlReplacements config element:
<UrlReplacements> <!-- The Url Replaces change the url listed in the event to valid public items Examples: This item changes the TFS url to a TeamPlain v1 url <Replace eventType="WorkItemChangedEvent" old=":8080/WorkItemTracking/WorkItem.aspx?artifactMoniker=" new="/workitem.aspx?id=" /> These items change the server location to a public host header: <Replace eventType="WorkItemChangedEvent" old="[ServerProductionEnviromentName]" new="[PublicProductionEnviromentUri]" /> <Replace eventType="WorkItemChangedEvent" old="[ServerDevelopmentEnviromentName]" new="[PublicDevelopmentEnviromentUri]" /> --></UrlReplacements>
This works by replacing values within the URL in the events. You specify the event type, what to look for and what to replace it by. This allows grater control and the integration of TeamPlain into your world. If a task is assigned to someone outside of your departmental sphere who you have given permission to TFS but who know nothing about it, they will still get an email that will link them through to TeamPlain.
And that is you all set. if you have installed the service and set the account that is used to run the service you should get no errors when starting. No guarantees though :)
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
TFS Event Handler in .NET 3.5 Part 2 - Handling Team Foundation Server Events
Guide to implementing a resilient Team Foundation Server event handler in .NET 3.5 using WCF, including service contracts, endpoints, …
TFS Event Handler for Team Foundation Server 2010
Explains how to create and customise event handlers for Team Foundation Server 2010, covering supported events for version control, builds, …
Team Foundation Server 2010 Event Handling with Subscribers
Explains how to create and deploy server-side event subscribers in Team Foundation Server 2010 using the ISubscriber interface to handle and …
Creating your own Event Handler
Learn how to create custom event handlers for Team Foundation Server by inheriting from AEventHandler, implementing IsValid and Run methods, …
TFS Event Handler in .NET 3.5 Part 1 - The Architecture
Explains designing a resilient, scalable TFS event handler in .NET 3.5, focusing on system architecture using Visual Studio diagrams for …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …