First thoughts on using the TFS API inside Sharepoint 2007

calendarJul 8, 2007 · 2 min read · Uncategorised  ·
Share on: linkedincopy

I have been looking at writing some SharePoint 2007 (MOSS) web parts to show information about TFS workitems. This turned out to be a bit more complex than expected.

I wrote a ASP.NET 2.0 webpart using the TFS WorkItem Tracking Web Project on Codeporject as a starting point. My first WebPart just listed workitems in a project. This went OK and the webpart worked fine in a simple ASP.NET Web Part Manager based test page.

Note: Workitem types are specific to the process template in use, this does mean you have to be careful when rendering data from work item, the fields you expect might not be there in all types of workitem, but that was not my major problem.

When I was happy with my first version I tried to load it into my test MOSS VPC, and I had problems, these were the steps I followed to get it working:

  • I copied  the mywebpart.DLL and mywebpart.PDB in the C:InetpubwwwrootwssVirtualDirectories8080bin directory (8080 was the port of my test MOSS server) Note: I later made the copying of these files a post build event in VS2005, but when I started it expect it to work - I was young and naive!
  • I copy the mywebpart.webpart file to C:InetpubwwwrootwssVirtualDirectories9080wpcatalog  (I had to create this directory). This file contained the following information that defined how the WebPart is listed in MOSS
                  Cannot import a TFS Web Part.                       TFS Web Part         A webpart that allows presentation of TFS data         FALSE            
  • I also copied the TFS DLLs that were in my VS2005 project's bin directory to C:InetpubwwwrootwssVirtualDirectories8080bin directory
  • When I tried to add the new webpart to a page, the page refused to render, I knew this was due to the WebPart not being trusted. I needed to edit the web.config in the C:InetpubwwwrootwssVirtualDirectories8080 directory to have the settings I required to allow my WebPart to be accessed:
   
           

<! edited the following to get error messages -->

<compilation batch="false" debug="true"

  • Now as I got more detailed error messages I saw that I needed the [assembly: AllowPartiallyTrustedCallers] attribute on my DLL, I added this and rebuilt the DLL. However, this did not fix the problem as the TFS DLLs also needed this attribute to but I could not add it to them as they were pre-compiled.
  • Just to prove the problem was the TFS DLLs I commented out the lines that called TFS DLLs and the WebPart render without a problem.
  • So I tried moving the TFS DLLs to the GAC, as this is a more trusted location, but it did not help.
  • I next edited the web.config again to reduce the MOSS security level

  

  • Once this was done I got a new error, a file access error, so it seemed the TFS DLLs were now trusted enough to be used - I was going in the right direction!
  • I used FIleMon on the server to check exactly which files were the problems and saw I had to give the MYSERVER/IUSR_MYSERVER user create rights to the directory C:WINDOWSsystem32inetsrvMicrosoftTeam Foundation1.0Cache, in fact the Microsoft directory did not exist. This seemed a strange user as the MOSS application pool was running under the Network Service account. This sort of problem is a good reason to use FileMon as it shows the failing file and user.

When all this was done, low and behold the WebPart leapt into life showing a list of Projects and their WorkItems on my TFS server. Now I need to do more to make this useful such as:

  • Get the user identify from SharePoint not a config file
  • Create an associated work item details webpart to allow editing and creation.
  • Sort out the CSS Styling
  • Make sure it works on our main 64Bit MOSS server (I have doubts about this one being possible) not just on 32Bit.
  • Add some AJAX support to make the user experience smoother.

I will post some more, maybe with some samples if it works.