I said I would post again when I had something to show in my TFS WorkItem webparts project, well here it is. I have created a pair of web parts, one to list all the work items and the other to display the details of a given item.
For testing I have create a single ASP.NET 2.0 web page that implements a WebPart manager. This needs to be setup to allow connection between the two WebParts. Note: if you use this sample you will probably have to recreate the connection between the web parts on the test page. Click the edit option (dropdown at top right) for either WebPart and use the connect option. When running it should look like this.
I had tried to use an ASP:Repeater control to display the list of workitems. I added a LinkButton to the first column to allow an item to be selected for display. The problem was that this button disappeared on a postback, a viewstate problem I could not resolve. I therefore swapped from a Repeater to a DataGrid which did not suffer this problem as it has a specific ButtonColumn type. However I left the Repeater code in the projects as it is nice worked example of how to programmatically add a Repeater, also I think it is potentially more flexible (if it worked!)
The details WebPart just does a list of all the fields in the WorkItem, this is because each type of WorkItem can have it’s own fields. This does not look that great as there is data the user does not need to see, but without the creating a display for each workitem type I cannot see another solution.
If you look in the tester’s web.config you will see the TFS section where you can specify TFS server, UID, Domain etc. The server must be filled in (and is shown on the list web part as a reminder as to what you set it to) but if the others are blank the user current authenticated identity in he browser should be used, if the other fields are filled in these are used instead.
Both these authentication models work fine in the test harness.
After I got the tester working I moved the DLLs onto my test SharePoint 2007 VPC, now this is not a simple operation, but this VPC had already had the changes I specified in my last post, so was fairly quick to do. In summary the steps are:
- TFS Client API DLLs in the GAC
- The SharePoint virtual server web.config edit to give full error messages, run a full trust, have my DLLs marked as safe and the TFS entries from the tester web site added.
- Copy my TFS webpart DLL to the SharePoint virtual server bin directory
- Copy the two .webpart files in the project to the SharePoint virtual server wpcatalog directory
- Add the CSS styles for the controls to SharePoint CSS file – but if you miss this out they still look OK.
Now my VPC was not in our main domain, so for testing I initially used hard coded UID and Domain in the web config. Once this was all done I could add the two WebParts to a page and used the connection option on the edit menu to wire them together, and low and behold it all worked.
I then added my test MOSS server to our domain, made sure the authentication was set to Windows and a valid TFS user account was set as the owner of the site.
I then removed the UID settings from the web.config and tried again, it failed. After debugging I could see my HttpContext.Current.User.Identity and Microsoft.SharePoint.SPContext.Current.Web.CurrentUser objects were the correct user, but the System.Net.CredentialCache.DefaultCredentials always returned what appeared to be blank credentials, a problem as this is the one used by TFS authenticate. Unfortunately neither of the others can be cast to the ICredentials interface required for TFS.
Problem 1: So at this point you are left with hard coded accounts details, not that useful. The options are to throw up a login form, or have the values set by properties on the webpart. I intend to continue to try to find a way around this problem.
Problem 2: As I said my test server is on a VPC and hence 32bit, but our live MOSS2007 servers are all running 64bit. I tried to install my WebParts on our live server, but was stopped as at this time as there are no TFS Client 64bit DLLs, and for some reason the TFS Client DLLs cannot be loaded with WOW64 by the MOSS server. I am trying to find out when we can expect to see 64bit DLLs (or a workaround)
So not a perfect job, but a good learning experience for both TFS and MOSS
You can download the samples here
In theory to get it running in the test harness you just need to load the soluion in VS.NET 2005:
- Make sure you can reference the TFS DLLs (usually in c:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies)
- Edit the TeamFoundationServer server entry in the test site web.config to point at your TFS server.
- As it is a WebPart based tested when first run a Database will be created in the test site’s APP_DATA directory
I am interest to here anyone comments.