Another stupid way to waste an hour or two…..

When developing SharePoint add-in try to remember if you put a previous version of the DLL in the GAC or not. I have just wasted a couple of hours trying to work out why a new version of a DLL is not being read from a site collection’s bin directory, when there was an old version in the GAC.

Of course this would not have been an issue if I had been checking the version number properly! A good argument for pair programming to avoid these stupid blind spots

First thoughts on using the TFS API inside Sharepoint 2007

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:\Inetpub\wwwroot\wss\VirtualDirectories\8080\bin 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:\Inetpub\wwwroot\wss\VirtualDirectories\9080\wpcatalog  (I had to create this directory). This file contained the following information that defined how the WebPart is listed in MOSS

<webParts>
  <webPart xmlns=”
http://schemas.microsoft.com/WebPart/v3″>
    <metaData>
      <type name=”BlackMarble.WebParts.TFS.WorkItemList” />
      <importErrorMessage>Cannot import a TFS Web Part.</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name=”Title” type=”string”>TFS Web Part</property>
        <property name=”Description” type=”string”>A webpart that allows presentation of TFS data</property>
        <property name=”AllowClose” type=”bool”>FALSE</property>
      </properties>
    </data>
  </webPart>
</webParts>

  • I also copied the TFS DLLs that were in my VS2005 project’s bin directory to C:\Inetpub\wwwroot\wss\VirtualDirectories\8080\bin 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:\Inetpub\wwwroot\wss\VirtualDirectories\8080 directory to have the settings I required to allow my WebPart to be accessed:

<!– In sectionGroups, to allow custom web.config entries –>
<sectionGroup name=”TeamFoundationIntegration”>
    <section name=”TeamFoundationServer” type=”MyNameSpace.TeamFoundationConfigurationManager” allowLocation=”true” allowDefinition=”Everywhere”/>
</sectionGroup>

<!– In Configuration, the hard coded details are just for initial testing –>
<TeamFoundationIntegration>
        <TeamFoundationServer server=”[my server]
userName=”[uid]” password=”[pwd]” domain=”[domain]” project=”[project]”></TeamFoundationServer>
    </TeamFoundationIntegration>

<!– In SafeControls –>
<SafeControl Assembly=”BlackMarble.WebParts.TFS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8ce1ffa442ef12af” Namespace=”BlackMarble.WebParts.TFS” TypeName=”*” Safe=”True” />

<! edited the following to get error messages –>
<customErrors mode=”Off” />
<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

<!– Edited <trust level=”WSS_Minimal” originUrl=”” /> to –>
   <trust level=”Full” originUrl=”” />

  • 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:\WINDOWS\system32\inetsrv\Microsoft\Team Foundation\1.0\Cache, 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.