TFS.Net

Remote deployment of an msi using PsExec

Dilip M — Fri, 11 May 2007 15:39:00 +0000

The last piece of the puzzle from our automated build and deploy setup was the ‘deploy’. We have InstallShield packages for most of our components and at first it appeared as though the remote deployment would be pretty simple using PsExec. However, after some investigation it appeared as though it was not quite as straightforward to pass parameters to an msi setup which would be kicked off by PsExec, all from within MSBuild.

The first problem, that multiple people have reported is that passing parameters to an msi install via PsExec seems to be problematic. One solution was to wrap the PsExec call within a batch file which resided on the deploy target machine.
Here’s the call within the batch file itself:
msiexec /i /q [Input parameters]

Note that the input parameters are optional. You must include double quotes if a parameter has whitespace.

The second part was to use an Exec task within MsBuild to kick off PsExec itself:

You might want to encrypt the password and pass it from within a custom task rather than have it floating around in cleartext.

Prior to the PsExec task I did a copy of all the setup files to the remote machine:

PsExec has a copy command but it works only for a single file setup.

Another alternative is to use the PsExec task in the SDC tasks library.

Choosing between mainline and cascading branch strategies

Dilip M — Tue, 27 Mar 2007 16:50:15 +0000

Recently there was a discussion on the MSDN forums on the branching strategies. The two approaches that were being discussed were cascading and the mainline approach. I thought I’d add my two cents here because we gave both approaches a try.
Initially the decision was taken to use the cascading model as it made it easier for devs to track the branching flow. Most devs in our team came from a VSS background and were not familiar with the concept of branching and concurrent development. However, we soon ran into a major roadblock. Here’s the issue we had:
We released v1.0 of our product and moved onto v2.0 development. The 2.0 branch was created off 1.0. But then there was the need for a maintenance release off 1.0, named 1.1. Since the 2.0 branch was already created, there was no way to insert another branch between 1.0 and 2.0. True, we could label the 1.0 branch with each maintenance release (1.1, 1.2 etc.) but this would not allow us to go back to an older version (say 1.0) and easily recreate a build since it wasn’t the latest in that branch. I say ‘easily’ because the TFS Team Build does allow us to specify a label and build off of that.
Given these problems, we decided to move to the mainline, or trunk, approach. This has been working well for us so far.
For those who have not seen this so far, a visual depiction of branch flow can be seen by right clicking on a particular folder in Source Control and selecting the ‘Branches’ tab. This makes it very easy to see the parent child relationships, and how to propagate merges between various branches.
Micheal Ruminer has a good post on branching strategies for those who are considering the pros and cons of each approach. Here’s a link to a really good whitepaper by Seapine SCM that I referenced when we were looking at what might suit our needs best.

TFS Build Service not recognizing TF Server

Dilip M — Mon, 26 Mar 2007 17:47:26 +0000

Due to the lack of hardware our initial setup for Team Build had the build service on the same machine as the source control server. To limit access to only TFS admins on the source control server we purchased another machine and reconfigured our build scripts to point to the new machine for the build. The thinking was that the build machine would allow a larger group of people access to debug any problems with failed builds, while still limiting access to the source control server itself.. While trying to run the build I received error # TF42053.

It’s a good thing that this error was pretty self-explanatory, unlike a few of the cryptic errors that TFS can throw at you. I edited the TFSBuildService.exe.config file and added the server name to the key ‘AllowedTeamServer’. The config file itself can be found on the build machine at at %ProgramFiles%/Microsoft Visual Studio 8/Common7/IDE/PrivateAssemblies. The server name must be entered EXACTLY in the format as specified in the error message, i.e., you cannot just mentioned the server name. Once this was done the Team Build service had to be restarted and the build was working again.

Something I hadn’t quite figured out was what triggered this error; I did run a few builds initially on the new machine without this server name entered in the config file. Anyway, since the change itself was pretty minor, I didn’t worry about it.

The correct way to remove permissions on a TFS branch

Dilip M — Thu, 08 Mar 2007 20:25:19 +0000

I was removing write permissions for the Development team from the branches that we already had in production. Initially I went and set the Checkin and Checkout permissions to Deny for the Contributors group. I was a little surprised when I tried to checkout a file in one of the branches and was locked out too! This in spite of the fact that I was a member of the Project Admins group. After some digging I found that setting any permission to Deny will lock every user belonging to that group, regardless of whether he or she is part of the Admins group. Doesn’t seem very intiutive to me.
Anyway, the workaround is to go the properties (right-click) of that folder and then go to the Security tab. There, the ‘Inherit security settings’ box, which is at the bottom of the page, should be unchecked. Then enable permissions selectively for those groups you wish to allow.

What is the purpose of the files created by the TeamBuild wizard?

Dilip M — Sat, 16 Dec 2006 04:21:58 +0000

Something that confused me initially was the purpose of the workspacemapping.xml and TFSBuild.rsp files. It was obvious that the build script itself was contained in TFSBuild.proj. After some digging I learned that the WorkspaceMapping.xml is used to cloak folders that are not relevant to the build, for e.g., folders that may form part of another build, folders where you store your documents etc. The folder that contains the source required for the build is included with the type ‘Map’. The LocalItem path does not seem to be relevant.

Cloaking means that the folder is not downloaded to the build machine, and any changesets or work items in that path are not included in the build log. Be aware that there is a bug in TFS that regenerates all changesets if folders are cloaked and then un-cloaked.

Now for the TFSBuild.rsp file that I mentioned in my previous post – this is used to supply command line parameters to the TeamBuild. One tip that I got from Dave McKinstry’s post was to skip initialize workspace, get files etc. which helped greatly when I was tuning my build script. Another option to speed up builds while testing is to set the DoNotDownloadBuildType property to true in the tfsbuildservice.exe.config file (on the build machine) and then restart the Team Build service for it to recognize the changed setting. This allows you to modify the build script directly on the build machine without having to deal with multiple checkins and checkouts.
The SkipClean, SkipInitializeWorkspace etc. can also be added in a PropertyGroup to your TFSBuild.proj file.

The extensibility of TFS

Dilip M — Sat, 02 Dec 2006 04:11:53 +0000

One of the biggest positives I have seen in TFS is the amount of thought Microsoft has put into making it extensible. Although TFS is a solid product, it is still a v1 product, and as such, there have been instances where we have needed to implement build-related functionality that was not available out of the box. For most of these all I’ve had to do is create a simple custom task and include it in the build script. The only pain point I have experienced here is attempting to debug the custom task. It gets pretty complex when attempting to create unit tests that simulate several variables being input from a TeamBuild. Other than inserting several Log.LogMessage calls I haven’t found anything else. If you have a better method I’d be interested to know it. Here is a list of overrideable targets which can be used to inject tasks.
A tip to make it easier to test builds (not just those with custom tasks): edit your .rsp file to skip clean, skip get latest source etc. The builds completes faster; once you’re done, these parameters can be removed.

Why this blog?

Dilip M — Fri, 01 Dec 2006 22:33:31 +0000

I work for a relatively small company in Toronto and we are in the process of moving from VSS to Team Foundation Server. Having worked with other SCM tools like ClearCase and PVCS in the past I was designated to lead this effort. We are a company that is growing and now there is a greater need for processes. I have worked for a couple of CMM level 5 companies in the past and it’s really interesting to be a part of an effort where processes are only being formulated.

Back to TFS – when I started digging around for information on TFS I found it somewhat hard to come by so I thought I’d share my learnings as well as vent on this blog. The TFS API in particular has led to many hours of frustration. It’s a big API, which is great because it makes TFS so extensible but the lack of documentation is frustrating. But the MS folks on the MSDN forums have been great in helping out in this area. However, combing through the forums for information can be time consuming so I thought it’d help other people in the same situation as myself by sharing the information here, in addition to other posts.

Since my efforts will be focused on TFS in the near future most of my posts will be TFS-centric. However, since a TFS implementation also involves process change, my posts will include my thoughts on the direction we’re taking, and why. From time to time I will add .Net-related items that I find interesting.