30 October 2007

VS2008 Beta 2 VPC updates available

Just a follow-up to my prior post about the VS 2008 Beta 2 VPCs problem.  Brian Harry has announced that the new VPCs have been made available for download to mitigate the expiring OS license issue.

"The final mitigation for our unexpectedly expiring VS/VSTS/TFS 2008 Beta 2 VPC is now in place.  Yesterday we uploaded new VPC images with the expirations changed.  Again, remember that the issue only affects VPC images.  If you installed the actual setups, there will not be any early expiration issue."   - Brian Harry

25 October 2007

Oops! VS2008 VPCs are expiring a bit sooner than advertised

Jeff Beehler has just announced that the VPC distributed with VS 2008 Beta 2 will expire earlier than expected.  Jeff wrote:

"We recently discovered that the VPCs we distributed as part of the VS2008 Beta2 release will expire on Thursday, November 1, 2007, much earlier than we had originally expected.  Since the timeout is at the OS level, we cannot automatically extend the timeout period.  As such we are currently in the process of reissuing the VPCs and expect to make them available early next week. "    - Jeff Beehler

He gives a method to move any data you may have in the VPC TFS' to the updated VPCs.

19 October 2007

TFS Installation Tidbits - Ports used by TFS 2005

When installing TFS in a single or dual server configuration you may have to modify your firewall to allow the Application Tier, Data Tier and Build Server to communicate.  Here are the ports used by the different parts of TFS.

Component Port
WSS 80
SharePoint Central Administration 17012
Team Foundation Server 8080
TFS Proxy 8081
TFS Build Remoting 9191
SQL Server 1433
SQL Server Browser Service 1434
SQL Server Monitoring 1444
SQL Server Analysis Services Redirector 2382
SQL Server Reporting Services 80

 I haven't reviewed TFS 2008 yet, but I would venture a guess that most, if not all, of these remain the same with possible additions.

18 October 2007

TeamBuild Tidbits - Test pass but results can't be published

Problem:  Your TeamBuild compiles successfully and the tests are run.  All tests pass but the build still fails.  This usually happens the first time you turn on tests in your build.  You check the build log and see:

Waiting to publish...
  Publishing results of test run 
  
xxx@yyy 2007-01-05 10:19:41_
    Any CPU_Release to 
    http://[YourTFSServer]:8080/
       Build/v1.0/PublishTestResultsBuildService.asmx...
  PublishRun: Access to the path
    '\\[server]\[dropshare]\[TeamProject]\
        [Flavor]\[BuildName]\TestResults\
        [some GUID]\[some filename].trx' is denied.
        MSBUILD : warning : PublishRun: Access to the path

MSBUILD : warning : PublishRun: Access to the path
      \\[server]\[dropshare]\[TeamProject]\
        [Flavor]\[BuildName]\TestResults\
        [some GUID]\[some filename].trx' is denied.
The previous error was converted to a warning because 
  the task was called with ContinueOnError=true.
Build continuing because "ContinueOnError" on the
  task "TestToolsTask" is set to "true".

Issue: The publication service is attempting to create a folder (named with a GUID) under the TestResults folder and set permissions on that folder without the proper permissions to do so.

Solution: Make sure that the account that runs your Application Tier web services has Full Control permissions to the DropShare folder.

TeamBuild Tidbits

As I catch up on my MSDN forums reading I've come across a number of tidbits that look like they could cause you to pull your hair out trying to resolve.  As I come across them I'm going to make a "tidbit" posting that will hopefully be concise and easily searchable. I may not be the first person to blog about the issue (and probably am not) but the more places they are documented, the easier they will be for someone to find when the need arises. :)

- Steve

TF.exe tidbit

I was doing some more catch-up reading and came across another interesting tidbit of information in an MSDN Build Automation forum post.

The author of the post was building a workspace by hand using an <Exec> task that called into TF.exe.  The build log contained the full command-line that the Exec task executed.  When he ran that command line in a Command Prompt, a dialog box appeared but during the Team Build, no dialog box shows up.  Confused, he asked where the /noprompt parameter was being added and why it wasn't visible in the command line in the build log. 

The answer, it seems, is that the dev team that built TF.exe made it really smart.  It checks to see if  it is running in an interactive (command prompt) or non-interactive( team build, etc.) session.  If it is running non-interactive it automatically sets the noprompt option for you.

Very nice!

16 October 2007

Frankenstein's Custom Task: A RoboCopy Custom Task for Team Build

I was recently working at a client on a TFS implementation.  They had been using TFS for a few months and had some cycles invested in their build process.  As part of the process, they  needed to deploy the compiled web sites out to a development test server so that they could review the code with their BAs prior to calling the Story complete.  They also had a requirement that they be able to have an indication that the deployment step was occurring during the build (in the Build Status page).

Their Team Build was constructed using the <Exec> task to call RoboCopy to do an "sync" between the drop folder and the deployment folder on the target web server.  Unfortunately, every time they ran this task the build broke.  It seems that RoboCopy doesn't follow the standard rules of command-line apps.  The standard rule is "Return code is 0 on success and anything else denotes an error condition". 

RoboCopy returns the following codes (from the RoboCopy documentation):

Hex Bit Value Decimal Value Meaning If Set
0x10 16 Serious error. RoboCopy did not copy any files. This is either a usage error or an error due to insufficient access privileges on the source or destination directories.
0x08 8 Some files or directories could not be copied (copy errors occurred and the retry limit was exceeded). Check these errors further.
0x04

4

Some Mismatched files or directories were detected. Examine the output log. Housekeeping is probably necessary.
0x02 2 Some Extra files or directories were detected. Examine the output log. Some housekeeping may be needed.
0x01 1 One or more files were copied successfully (that is, new files have arrived).
0x00 0 No errors occurred, and no copying was done. The source and destination directory trees are completely synchronized.

 

So as you can see, if RoboCopy returns the expected zero for success it really means that "Nothing was done."  A successful run is actually denoted by any Return Code less than 8.

What's a consultant to do?  Why I Googled up "MSBuild RoboCopy" and was rewarded with a link to the MSBuild Community Tasks on Tigris.org.  Sweet!  I knew that they had code to do what I wanted, so I grabbed it from their repository (thanks guys).  This code is for a straight MSBuild task and therefore couldn't talk to Team Build (and by extension TFS). 

To get that functionality, I remembered an article by Aaron Hallberg entitled "Adding BuildSteps to Team Build Through a Custom Task."  I brought up the article and nabbed that code too.  I also had some code laying around from earlier custom tasks I wrote to wrap command-line tools since I needed to evaluate and correctly interpret RoboCopy Return Code. 

With all of this code in hand I went down to my mad-scientist lab to cobble together the Frankenstein's Monster of custom tasks, a RoboCopy task that will correctly evaluate the return   code and add a BuildStep to a Team Build. [Evil laugh here]

To make this work I had my RoboCopy task inherit from Aaron's TeamBuildTask to get me the BuildStep message functionality.  Accordingly, I have to implement the GetBuildStepName, GetBuildStepMessage, and ExecuteInternal methods.  I then stuffed the Tigris.org RoboCopy code into the class to do the hard work of adding the task parameters and grabbing the support methods to correctly build the command line.  Afterward, I filled the ExecuteInternal method with my code that spins up a Process, redirects STDOUT and STDERR into accessible buffers and runs the RoboCopy command using the command line provided by Tigris' GenerateCommandLineCommands method. 

After the RoboCopy process finishes, I have to evaluate the Return Code from the Process to determine if an actual error occurred.  If one occurred, I write the error (from STDERR) to the MSBuild log file with high importance and return False from the task to let MSBuild know about it.  If the Return Code was less than 8, everything is well so I return True to MSBuild and everything runs as normal.  In either case I write the contents of STDOUT to the MSBuild Log file with low importance. 

I've put links below to the solution and binaries.  This custom task could easily be updated to call any command-line tool while logging BuildSteps to the Team Build.  This task will only work under Team Build because it requires a BuildURI and TeamFoundationServerURL parameters but it could be easily modified to remove the Build Steps and work under MSBuild alone.

Let me know what you think...

 

Compiled Assembly is here.

Source Code is here.

11 October 2007

Microsoft really wants to know how/if/where you use MSF Guidance in TFS

Jeff Beehler from Microsoft has posted a link to a survey to get your "thoughts and feedback" on MSF usage in real world projects that use TFS.  It's good to see that Microsoft is actively pursuing feedback from the wider TFS community.  Bravo!

I highly recommend that you take this anonymous survey and let the team know what you do and don't want and what you use and don't use in the MSF process guidance.  They are also looking for how to better integrate the guidance within Team Explorer and VSTS.

Here's your chance to let then know what you want.  Here's the link to Jeff's posting, the survey link is there...

http://blogs.msdn.com/jeffbe/archive/2007/10/11/please-give-us-your-thoughts-on-msf.aspx

04 October 2007

Full blown implementation of TFS not for the "faint of heart"

I was just reading a blog posting by David J. Anderson entitled "Team Frustration Server".  It describes his first year of a TFS implementation from a middle management viewpoint.  It's is very well balanced, not all rosy but very real. 

I'm linking to this article here so that I'll be able to point back to it in the future when a client has been sold TFS as a "VSS Upgrade" as opposed to an endeavor that rivals an Exchange rollout in complexity and resources. 

Look like I'll have to go back and read some of his other posts to see if there are any more gems here.