Steven Wright Blog

In my other blogs entries I mention that I have been looking into building a Team Foundation Server Data Warehouse Adapter.   After I got my initial proof of concept version working, I started to extend it to get a list of available builds from TFS and then import the output of Source Monitor – a popular free code metrics tool. Now I must state that I am not a natural .NET coder. My normal day-to-day work is based around the SQL Server technology stack. I do have some .NET coding skills but generally just enough for what is need in and around SQL Server. So I asked my colleague, Howard van Rooijen who is one of our top .NET coders, to have a look at my code and give me some hints. This provide me with a great opportunity to learn from Howard about some more advance Design Patterns,  Visual Studio tips and tricks , and how to effectively use some tools I’ve not used before to help me write better code. The first thing Howard did was install the following on my machine: ...

As mentioned in a previous blog I would like to explain some of the steps I took to get my custom data warehouse adapter to work.  I am going to start from the beginning just so that I have an easy starting point.  The code I show here was based upon my POC and written in C#. 1. Create a new C# Class Library project in Visual Studio. Then add references at least to the following assemblies: Microsoft.TeamFoundation.dll, Microsoft.TeamFoundation.Client.dll, Microsoft.TeamFoundation.Common.dll, Microsoft.TeamFoundation.Warehouse.dll and System.Web. As I need to connect to the build server I added Microsoft.TeamFoundation.Build.Common.dll and Microsoft.TeamFoundation.Build.Client.dll 2. Then specify the use of the IWarehouseAdapter interface. 3. Implement IWarehouseAdapter.RequestStop which only sets a stop flag to true which can then be tested by the other methods periodically. 4. Implement the IWarehouseAdapter.Initialize. This method this where I need to store objects tha...

I have been investigating a way of adding more metrics about our builds into the Team Foundation Server 2008 warehouse.  This would then allow us to measure quality of our code over time by other metrics than the just method offered by the Team Foundation Server 2008. So my goal was to create a new fact table and link this to build dimension.  The reason for building a fact table was the metrics as I would want to do some aggregation against them; this would mean I need to treat them as measures and measures only live in a fact table.  I also wanted a separate fact table so my adapter doesn’t impact the standard TFS adapters.  As my facts would be generated by builds it would mean that facts would link to the build which why I used the build dimension.  Also I found out later I had to also include the Team Project dimension as well. I managed to find some useful links that helped me write my adapter: http://msdn.microsoft.com/en-us/library/bb130342.aspx -...