1. Followed the pre-setup instructions to the T.
2. Run the installer; health check fails. SQL Server is the wrong version (2008 RTM); can’t find analysis services, NOTHING.
3. Hmm… must need SQL 2008 SP1. Install it via Windows Update.
4. Try again; health check fails. Wrong version of SQL Server, again.
5. Google – get a solution.
6. Follow those instructions to the T.
7. Installer CRASHES. Each time it does this I need to reboot.
8. Eventually just delete the SQL Server version check from hcpackages.xml
9. It looks like it’s installing now.

16 hours later. TFS Server 2005 took me merely 4-5 hours (did it twice). Considering it’s a test-bed server where I am going to continue working on integrating K2 with TFS Server (we are going to be using K2 to automate our builds) this was just plain ridiculous.

It’s clever, and that’s about it, to use Sharepoint. It seems as though TFS might have started off as a Sharepoint extensibility test. Things would be far easier were it not for the whole Sharepoint dependency (and analysis and reporting – I don’t need this).

These guys need to take a hint from the ASP.net team.

The solution isn’t obvious – simply right click on suspect events and view the code (having the XOML file open is fine – no need for individual CS files). When you build with the XOML open you will get two errors for each real error – one will point to Workflow.targets and the other to the actual file (line number and everything).