Michael Blake's Blog

We’ve got a VS2010 TFS Beta 2 server going on a VM. Here are some more hints…

- Follow this guide or Google for one:

- Create a DOMAIN user called DEV\TFSReports. The TFS server must also be on a domain.

- An install with no projects takes ~18GB (windows, SQL, WSS, TFS) so make sure you have at least a 30GIG drive.

- Make sure you have Windows 2008 SP2 an all its updates.

- I’m not sure who you should login as while installing. A domain account helps so you don’t keep getting prompted when adding domain users. I used the DEV\TFSReports.

- Make sure the reports user can login locally. http://blogs.msdn.com/ablock/archive/2008/09/18/setting-the-properties-the-log-on-as-a-service-and-allow-log-on-locally.aspx. If you don’t, SharePoint won’t work.

- Don’t add any users to SQL.

- Don’t worry about SharePoint app pool warning when configuring TFS.

- Add DEV\Developers (or people you want to create projects) to the Contributors on the Reporting Service admin site http:\\tfs2010\Reports (Note; the Reports site is not listed in IIS). This fixes the TF30224 error when a user tries to create a new project.

- If SharePoint fails, you can try to re add the extensions from Programs and Features > click Add features (not repair). http://social.msdn.microsoft.com/Forums/en-US/tfsprerelease/thread/e3f80d66-2d8a-46b1-a7da-efb61d86abbc

- You need to add domain users to a few places before creating a project: http://msdn.microsoft.com/en-us/library/dd547204(VS.100).aspx

- I didn’t manage to create the WSS site under site due to SharePoint permission issues. (I’ll update this blog when I figure it out)

- Don’t worry about the object not set (Beta 2?) error when adding a project, just re add the project to VS.

- Make sure you add Task before checking the portal/reports. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499387. This will get rid of the rsInvaildReportParameter for the WorkItemTypeParam after 30mins or so.

The scrum stuff looks good but its hard to tell until you use it. http://msdn.microsoft.com/en-us/library/dd997796(VS.100).aspx 

Next steps include getting a Build server and a Test Controller going. Lab management requires Hyper-V which Joe Gough is sorting out.

Cool. M

Comments welcome.

We want to be able to control the version of each of our releases. This was being done by leaving the Assembly Info to 1.0.*

Soon it was time to release and we needed greater control of the version number. On a previous project we had a Version.xml file that was stored in source control. This was “Got” on each build, read in, +1’d, updated and checked back in. It also updated a comment (RegEx replacement) in the AssemblyInfo.cs file with the new version number. We also share the Version.cs file by adding it as a link to each project (the dropdown on the Add button when adding an existing file to project)

The drawbacks to this were that you had to prefix the comment when you checked in with “*** NO_CI” and you had to manage the workspaces to get the latest. It was also to set the build number as you had to perform a check in.

This time, there was a check-in policy that prevented checking the version file back in. Instead of solving this (it looked like its was going to be a custom task) we have moved to a version file next to the Drop folder of the build server (on a network share).

Now we can have different version files on the network share and the release manager can update the version numbers as required. The revision number is still incremented by the msbuild scripts. This file is also updated once the build completed with the location of the drop. The last good drop path is used when automatically deploying.

Note we have also had problems with the difference between FileVersion and AssemblyVersion. http://support.microsoft.com/kb/556041

Branching

So that we can support new work and bug fixes, we have used TFS Source control to branch releases.

After you have created a branch, you need to create a new build type. It’s just as quick to compare the previous build type and just update the version number and path. You must then also create a \\projectbuildserver\Public\Versions\Branch_2.1.3.xml file and set the version number up. The project contains information about updating the xml file (note posted).

This means that each branch is under CI with shippable build popping out after each check in.

Note that labels are removed when the builds are removed. So if the retention policy removes them, the label is lost. To stop this, keep all builds (if you have the space) or mark a build as retain indefinitely on the completed builds window.

Once the build is completed, the version.xml file is updated with the location of the build so that a deployment process can always get the latest.

kk. Comments welcome.