Posts

Had an interesting issue during and upgrade from TFS 2012 to 2013.2 today. The upgrade of the files proceeded as expect and the wizard ran. It picked up the correct Data Tier, found the tfs_configuration Db and I was able to fill in the service account details. However, when I got to the reporting section it found the report server URLs, but when it tried to find the tfs_warehouse DB it seemed to lock up, though the test of the SQL instance on the same page worked OK. ...

Having installed my TFS Alert DSL today onto a client’s TFS 2013.2, I have realised some of the documentation was a little unclear. So I have have just updated the download page to provide an easy means to get The actual DSL implementation (without rebuilding the source) A command line tool to create an event source in case you want log to the Windows event log Hope this helps

The problem Today I found I had a problem when trying to associate a Release Management 2013.2 release pipeline with a TFS build. When I tried to select a team project the drop down for the release properties was empty. The strange thing was this installation of Release Management has been working OK last week. What had changed? I suspected an issue connecting to TFS, so in the Release Management Client’s ‘Managing TFS’ tab I tried to verify the active TFS server linked to the Release Management. As soon as I tried this I got the following error that the TFS server was not available. ...

I have just submitted a session for DDDNorth 2014, which is at the University of Leeds on Saturday 18 October. There is still time for you to submit yours Session submission

Rik recently posted about the work we have done to automatically provision TFS build agent VMs. This has come out of us having about 10 build agents on our TFS server all doing different jobs, with different SDKs etc. When we needed to increase capacity for a given build type we had a problems, could another agent run the build? what exactly was on the agent anyway? An audit of the boxes made for horrible reading, there were very inconsistent. ...

I am currently rebuilding our TFS build infrastructure, we have too many build agents that are just too different, they don’t need to be. So I am looking at a standard set of features on a build agent and the ability to auto provision new instances to make scaling easier. More on this in a future post… Anyway whilst testing a new agent I had a problem. A build that had worked on a previous test agent failed with the error ...

Whilst working on an automated build where I needed to target a specific project I hit a problem. I would normally expect the MSBuild argument to be /t:MyProject:Build Where I want to build the project Myproject in my solution and perform the Build target (which is probably the default anyway). However, my project was in a solution folder. The documentation says the you should be able to use for form ...

If you are doing any work with Azure Cloud Applications there is a very good chance you will want your automated build process to produce the .CSPKG deployment file, you might even want it to do the deployment too. On our TFS build system, it turns out this is not a straight forward as you might hope. The problem is that the MSbuild publish target that creates the files creates them in the $(build agent working folder)sourcemyprojectbindebug folder. Unlike the output of the build target which puts them in the $(build agent working folder)binaries folder which gets copied to the build drops location. Hence though the files are created they are not accessible with the rest of the built items to the team. ...

All teams have ‘Stakeholder’, the people the are driving a project forward, who want the new system to be able to do their job; but are often not directly involved in the production/testing of the system. In the past this has been an awkward group to provide TFS access for. If they want to see any detail of the project they need a TFS CAL, expensive for the occasional casual viewer. ...

My Channel9 Guy has a new MVP badge