I have been trying to get a simple means for our clients to log faults into our TFS system whilst inside our MOSS2007 based customer portal. I had been suffering from two major problems as my previous posts mentioned. However, I now have some solutions or at least workarounds:

  • Historically all users who connected to the TFS server needed a Team Foundation Client CAL - this issue has been addressed by changes in licensing for TFS by Microsoft; basically it is now free to look at work items and add bugs
  • The way the SharePoint and TFS APIs handle user identity (SPUser & ICreditial) do not match, and are not improbable. There is no way round the user having to reenter their user credentials for each system - so my web part logs into TFS as a user set via it’s parameters, this is not the same user as the credentials used to authenticate into SharePoint, it is in effect a proxy user for accessing TFS

So where does this leave us?

image

I have posted a set of sample code that provides

  • A web part that lists work items
  • A web part that shows the details of a work item (using the first webpart for all communications to the TFS server)
  • An ASP.NET test harness
  • A .WSP and batch file to install the web parts on a SharePoint Server

ASP.NET Usage:

  1. Load the solution in VS2008 (if you need to use VS2005 you will need to recreate the solution file, and point at the right TFS API DLLs, but everything else should work)
  2. Run the test harness project (note as we are using webparts it will have to create a local ASPNETDB.MDF files the first time it runs. The DB contains the config for the webparts so you will see nothing on the first loading until you setup the parameters)
  3. In the test page select the edit mode at the top of the page, then edit the list webpart in WebPartZone1, enter the following:
    - TFSServerURL – the TFS server e.g. http://tfs.mydomain.com:8080
    - TFSDomain – the domain used to authenticate against e.g. mydomain
    - TFSUsername – the user name to connect to the TFS server as, we create a dedicated user for this webpart to login as.
    - TFSPassword – the password used to authenticate with (shown in clear text)
    - TFSAllowedWorkItemTypes – a comma separated list of work item types to be listed in the control, must match types in the [System.WorkItemType] field in the TFS DB. Depending on the process template in use the types will vary but as a start in most templates there is a ‘bug’ type.
    - TFSDefaultProject – the name of the default TFS project to select on loading, can be left blank
    - TFSPagingSize – the number of rows to show in the list of work items
    - TFSShowOnlyDefaultProject – if this is set only the default project is listed in the available projects – this means a single TFS user, which can see many projects, can be used for different webpages and the project shown locked down with this parameter
    - TFSUsePaging – set if the list of workitems should be page
  4. Once this is all done and saved you should be able to a list of projects and workitems in the first webpart.
  5. To wire the two webparts together select the connection mode radio button at the top of the page
  6. On the web part in WebPartZone2 select the connect option
  7. In the connections zone that appears create a new connection to link the two webparts
  8. Once this is done you should see the detail of any given workitem when it is selected from the list. The problem is you see all the fields in the work item (useful for debugging)
  9. Put web page back into edit mode and edit the settings on the details web part
    - TFSFieldsToShow – a comma separate list of field names to be shown.
    - TFSShowAllField – if checked the TFSFIeldsToShow is ignored
  10. When all the configuration is done you have the option to create new bug workitems and add notes to existing ones.

If you want to use the webparts in SharePoint you need to install the feature pack using the .WSP package - I assume anyone doing this will know enough about WSP files and SharePoint to get going.

This all said it is not as if there are not still problems and qwerks:

  • You do need the TFC client on the server hosting the webparts, or at least the referenced DDLs - bit obvious really that one. 
  • When try to connect to TFS you might get an error about not being able to access the TFS Cache - use SysInternals filemon (or maybe the event logs) to check the directory being used and you will find the problem concerns the user running the hosting process (usually a member of the IIS_WPG group) not having rights to fully access the cache directory. Also it is a good idea to delete all cache files before retrying as some people report they had to rebuild the cache to clear the error.
  • Interesting point I discover which altered the design - Though the pair of webparts worked perfectly in an ASP.NET test harness, the connection options, when in SharePoint, were grey’d out. Turns out you have to add a second parameter to the consumer declaration else the default name is used for all webparts, which confused SharePoint e.g.

[System.Web.UI.WebControls.WebParts.ConnectionConsumer(“Work Item List Consumer”, “wilc”)] // the second param is an ID for connection
public void InitializeProvider(IWorkItemListToDetails provider)
{
      this.workItemListProvider = provider;
}

However the last problem was negated by the fact that in ASP.NET you can have a pairs of connections to get bi-directional communications between web parts. In SharePoint you are only allowed a single connection between any two webparts. Hence the current design using some strange boolean flags and logic to manage call backs in the pre-render stage. I left the older code in place, commented out, as a sample.

  • And the killer problem for me - you only can run these webparts on a 32bit SharePoint as there there are no 64Bit TFS DLLs. A major problem for us as our SharePoint servers are 64Bit. We need to wait for Rosario it seems before TFS moves to 64bit. Even though 32bit CTPs are available for Rosario as yet there is no date for a 64Bit CTP. I also checked, and WOW64 will not help to wrapper the 32Bit DLLs for a 64Bit OS. I have checked all this with Microsoft support.

So what we have here is a sample solution for 32bit environments. I am going to modify this to work for 64bit by putting all the TFS API bits in a separate WebService to host on a 32Bit server. I will post about this went it is done